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:
(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 ...
}
The implementation of this is straightforward. It simply reads the
exportname global from the server and returns it. It also doesn't
change the existing API at all.
(2) A better way might be to bump the API version to 3 and that would
allow us to change the open() callback:
static void *
myplugin_open (int readonly, const char *exportname)
{
... Do something based on the export name ...
}
This is cleaner but is obviously a larger change. Also if we were
going to bump the API version I'd want to at the same time do all the
other things we are planning for API 3, and that potentially makes it
a much bigger deal:
https://github.com/libguestfs/nbdkit/blob/b485ade71464fc351828e2fcce54464...
It has the advantage of making it easier to access the export name
from sh plugins, since those don't have access to nbdkit_* API calls
(or at least we haven't thought about how we would do that).
Thoughts?
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages.
http://libguestfs.org