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

[Martin Kletzander]

On Sat, Sep 21, 2019 at 08:59:54PM +0100, Richard W.M. Jones wrote:
>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.
>

Since the probing doesn't work exactly how I thought (as you described in the
other thread).  So I guess requiring the null plugin is enough until there is
--dump-filter or something similar 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20190921/abcff9d3/attachment.sig>