[Libguestfs] [PATCH nbdkit v2] PROPOSED: server: Implement list_exports.

[Richard W.M. Jones]

[continuing ...]

On Wed, Jul 29, 2020 at 09:22:31PM -0500, Eric Blake wrote:
> We need something similar for a filter to be able to request a
> single shared .open of the underlying plugin (shared by all
> connections into the filter), and which has a lifetime visible
> between the filter's .after_fork and .unload regardless of how many
> .open/.prepare/.close client connections come and go, rather than
> having to repeat a next_ops->open for each filter .open.  Kind of
> the opposite of the reopen filter (which uses multiple calls into
> next_ops->open from a single .open to the filter).

I'm not sure why only "single" & "shared".  Why not allow filters to
open plugin connections on their own as a general mechanism?  This
would solve the filter background threads problem, and the list
exports problem too.

This seems to solve the problem without needing to share one plugin,
unless I'm missing some bigger point.

> While filters like tar and ext2 will probably benefit from doing
> explicit sharing of a single underlying plugin, it would also allow
> us to create a new --filter=shared that can be thrown in front of
> any plugin (rendering the existing 'nbdkit nbd --shared' obsolete in
> favor of 'nbdkit nbd --filter=shared').
> 
> Basically, I'm thinking we need the following filter-only functions:
> 
> int nbdkit_plugin_open(int readonly, struct nbdkit_next_ops **next_ops,
>                        void **nxdata);
>
> which a filter can call at any point between .after_fork and .unload
> to open a distinct connection into the plugin independent of any
> filter clients, and which returns by reference a next_ops/nxdata
> pair that the filter can then use in place of waiting for a
> per-connection next_ops/nxdata passed through
> .prepare/.can_write/.pread/etc.
> 
> void nbdkit_plugin_close (struct nbdkit_next_ops *next_ops,
>                           void *nxdata);
> 
> which a filter later calls to close its own connection into the
> underlying plugin.  Any plugin that uses these new functions would
> probably implement a .open that does NOT call next_open(nxdata),
> because it instead reuses the shared handle that it opened globally.

Agreed, except that filters can call this as often as they like.

Not sure this actually solves the list_exports problem however since
presumably list_exports still happens before open so it woudn't appear
in the next_ops struct?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v