[Libguestfs] [nbdkit] Access export name from plugins

[Richard W.M. Jones]

On Tue, Sep 10, 2019 at 07:58:49AM -0500, Eric Blake wrote:
> On 9/10/19 5:01 AM, Richard W.M. Jones wrote:
> > Of course at the moment nbdkit parses the NBD export name option but
> > doesn't really do anything with it (except logging it).
> > 
> > I wonder if we should make this available to plugins, in case they
> > wish to serve different content to different clients based on the
> > export name.  Note I'm not suggesting that we use this feature in any
> > existing plugins.
> > 
> > If we wanted to do this there seem like two possible ways to do it:
> 
> at least two ways.
> 
> > 
> > (1) Add a call, like nbdkit_export_name, which plugins could call from
> > any connected method to get the current export name, eg:
> > 
> > static void *
> > myplugin_open (int readonly)
> > {
> >   const char *export = nbdkit_export_name ();
> > 
> >   ... Do something based on the export name ...
> > }
> 
> I would also consider adding an optional callback:
> 
> struct nbdkit_export {
>   char *name;
>   size_t size;
>   // maybe other fields for supporting NBD_OPT_INFO...
> };
> 
> const nbdkit_export *(*list_exports) (void);

I see this as needed too, but solving a slightly different problem
from the one which Xiubo Li has.

However there's an interesting point here: Should the list of exports
be handled separately or should it be integrated?

For example, we could imagine first implementing nbdkit_export_name as
I described, and ignoring the NBD_OPT_LIST problem.  Later we decide
to implement NBD_OPT_LIST by adding a .list_exports callback.  But a
(bad) plugin could answer with a completely different list of exports
from what it supports in the .open call.

Or we could try to find a way to tie these two together, but I'm not
clear at the moment how we would do that.

(I'm inclined to think this is over-designing things and it doesn't
matter very much if a plugin gives the wrong answer when asked to list
exports.)

[...]
> Note that with sh plugins, we could still make things work with v2, as
> follows:
> 
> sh_open() calls nbdkit_export_name() unconditionally, prior to forming
> the command line for calling into the script.  Then we alter the command
> line we pass to the script:
> 
> /path/to/script open <readonly> <exportname>
> 
> where the sh plugin always gets to know what export name the client
> chose, thanks to the new exportname parameter.  Compatibility-wise,
> older scripts fall in one of two categories: either they ignore
> unexpected parameters (no change required), or they choke because
> exportname was unexpected (but it's a one-line change to the script to
> deal with it).  New scripts run against an older nbdkit that did not
> provide the exportname parameter will see "$3" as empty (if the script
> runs under 'set -u', then spell things "${3-}").

sh plugins really should ignore extra parameters they don't know
about.  We should probably say that in the man page.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/