Re: [Libguestfs] [nbdkit] Access export name from plugins
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/