Re: [Libguestfs] [PATCH nbdkit] server: Pass the export name through filter .open calls.
On 7/21/20 7:41 PM, Eric Blake wrote:
> @@ -148,7 +166,7 @@ ext2_prepare (struct nbdkit_next_ops
*next_ops,
> void *nxdata, void *handle,
> struct ext2_inode inode;
> int64_t r;
> CLEANUP_FREE char *name = NULL;
> - const char *fname = file ?: nbdkit_export_name ();
> + const char *fname = file ?: h->exportname;
Hmm - we already pass the same 'readonly' state to filter's .prepare,
but not to backend_prepare(), which has to reconstruct it. Would it be
easier to also change the signature of backend_prepare() to take both
the original readonly and exportname passed to backend_open(), rather
than making the filter have to save it off in the filter? It looks like
protocol-handshake.c is the only caller, and still has everything in
scope at the time.
Nope, we can't. It's because the sequence is:
backend_open("clientname")
outer_filter.open("clientname")
next_open("outername")
inner_filter.open("outername")
next_open("innername")
plugin.open("innername")
backend_prepare()
backend_prepare()
backend_prepare()
plugin.prepare()
inner_filter.prepare()
outer_filter.prepare()
while protocol-handshake.c has the same "clientname" to pass to both
backend_open() and backend_prepare(), the outer-to-inner order of .open
is (intentionally) opposite the inner-to-outer order of .prepare, and
the name passed to plugin.open has indeed left scope. Unless we want
backend.c to start storing the name passed into backend_open().
> +++ b/filters/log/log.c
> @@ -227,11 +227,12 @@ output_return (struct handle *h, const char
> *act, uint64_t id, int r, int *err)
> /* Open a connection. */
> static void *
> -log_open (nbdkit_next_open *next, void *nxdata, int readonly)
> +log_open (nbdkit_next_open *next, void *nxdata,
> + int readonly, const char *exportname)
> {
> struct handle *h;
> - if (next (nxdata, readonly) == -1)
> + if (next (nxdata, readonly, exportname) == -1)
> return NULL;
Pre-existing - the log filter should include the exportname somewhere in
its output log. Well, nothing like the present to fix it ;)
I did that in the meantime, so you'll need a slight rebase.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org