Libguestfs - Sep 2019 - Re: [PATCH v4 07/12] v2v: nbdkit: Add the readahead filter unconditionally if it is available.

On Fri, Sep 20, 2019 at 09:33:06AM -0500, Eric Blake
wrote:
> Checking for file existence for filters is somewhat less fragile than
> for plugins, because all filters are built in-tree (we've specifically
> documented that we don't provide ABI guarantees for filters, so the
only
> sane way to use a filter is to compile it at the same time/version as
> the nbdkit binary that will load it).  But you do have a point that
> checking for files is still more fragile than just asking nbdkit whether
> a given filter exists:
> 
> $ nbdkit --dump-plugin --filter=nosuch null
> nbdkit: error: cannot open filter 'nosuch':
> /usr/lib64/nbdkit/filters/nbdkit-nosuch-filter.so: cannot open shared
> object file: No such file or directory
This is definitely the best we can do now, and I've posted a patch
suggesting this change for the nbdkit-probing(1) man page.

However it's not without a subtle problem: It requires the null plugin
to be present.  It's possible to ship nbdkit on its own.  On Fedora
try installing just the nbdkit-server package.  The null plugin won't
be available so this command will always fail.

So we do also need to change nbdkit to allow easier probing for
plugins or filters in the long term.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

On Sat, Sep 21, 2019 at 03:54:11PM +0100, Richard W.M. Jones
wrote:
>On Fri, Sep 20, 2019 at 09:33:06AM -0500, Eric Blake wrote:
>> Checking for file existence for filters is somewhat less fragile than
>> for plugins, because all filters are built in-tree (we've
specifically
>> documented that we don't provide ABI guarantees for filters, so the
only
>> sane way to use a filter is to compile it at the same time/version as
>> the nbdkit binary that will load it).  But you do have a point that
>> checking for files is still more fragile than just asking nbdkit
whether
>> a given filter exists:
>>
>> $ nbdkit --dump-plugin --filter=nosuch null
>> nbdkit: error: cannot open filter 'nosuch':
>> /usr/lib64/nbdkit/filters/nbdkit-nosuch-filter.so: cannot open shared
>> object file: No such file or directory
>
>This is definitely the best we can do now, and I've posted a patch
>suggesting this change for the nbdkit-probing(1) man page.
>
>However it's not without a subtle problem: It requires the null plugin
>to be present.  It's possible to ship nbdkit on its own.  On Fedora
>try installing just the nbdkit-server package.  The null plugin won't
>be available so this command will always fail.
>
>So we do also need to change nbdkit to allow easier probing for
>plugins or filters in the long term.
>
Is it usable without any plugins?  Does the null plugin take much space?  I
wouldn't think so.  Would it be too messy to just ship the null plugin
unconditionally, even if just for this particular purpose?

On the other hand any program that relies on such probing to work might depend
not only on nbdkit, but also on the null plugin.
>Rich.
>
>-- 
>Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
>Read my programming and virtualization blog: http://rwmj.wordpress.com
>virt-builder quickly builds VMs from scratch
>http://libguestfs.org/virt-builder.1.html

On Sat, Sep 21, 2019 at 09:45:16PM +0200, Martin Kletzander
wrote:
> On Sat, Sep 21, 2019 at 03:54:11PM +0100, Richard W.M. Jones wrote:
> >On Fri, Sep 20, 2019 at 09:33:06AM -0500, Eric Blake wrote:
> >>Checking for file existence for filters is somewhat less fragile
than
> >>for plugins, because all filters are built in-tree (we've
specifically
> >>documented that we don't provide ABI guarantees for filters, so
the only
> >>sane way to use a filter is to compile it at the same time/version
as
> >>the nbdkit binary that will load it).  But you do have a point that
> >>checking for files is still more fragile than just asking nbdkit
whether
> >>a given filter exists:
> >>
> >>$ nbdkit --dump-plugin --filter=nosuch null
> >>nbdkit: error: cannot open filter 'nosuch':
> >>/usr/lib64/nbdkit/filters/nbdkit-nosuch-filter.so: cannot open
shared
> >>object file: No such file or directory
> >
> >This is definitely the best we can do now, and I've posted a patch
> >suggesting this change for the nbdkit-probing(1) man page.
> >
> >However it's not without a subtle problem: It requires the null
plugin
> >to be present.  It's possible to ship nbdkit on its own.  On Fedora
> >try installing just the nbdkit-server package.  The null plugin
won't
> >be available so this command will always fail.
> >
> >So we do also need to change nbdkit to allow easier probing for
> >plugins or filters in the long term.
> >
> 
> Is it usable without any plugins?  Does the null plugin take much space?  I
> wouldn't think so.  Would it be too messy to just ship the null plugin
> unconditionally, even if just for this particular purpose?
Right!  My original plan was that we could change the API to drop all
required callbacks.  The "null" plugin would become the plugin which
had no callbacks and could therefore be built in to the nbdkit binary.

Unfortunately my plan doesn't quite work because the null plugin has a
config parameter (nbdkit-zero-plugin is more like this "null" plugin).
Oh well.
> On the other hand any program that relies on such probing to work
> might depend not only on nbdkit, but also on the null plugin.
Indeed, or as you say above we could package one of the regular
plugins with the server to guarantee it is always available.

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