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/