Libguestfs - Mar 2018 - Re: [nbdkit PATCH v3 15/15] RFC: plugins: Add back-compat for new plugin with old nbdkit

On Thu, Mar 08, 2018 at 05:03:11PM -0600, Eric Blake
wrote:
> If we bump NBDKIT_API_VERSION, we have forcefully made older
> nbdkit reject all plugins that opt to the newer API:
> 
> $ nbdkit ./plugins/nbd/.libs/nbdkit-nbd-plugin.so --dump-plugin
> nbdkit: ./plugins/nbd/.libs/nbdkit-nbd-plugin.so: plugin is incompatible
with this version of nbdkit (_api_version = 2)
> 
> But with a bit of finesse, we can make opting in to FUA support
> orthogonal to NBDKIT_API_VERSION, by introducing a new witness
> level that the user controls, and by providing sane fallbacks
> so that newer plugins correctly populate the fields expected by
> older nbdkit.
> 
> ---
> v3: rework entirely, add new variable instead of NBDKIT_API_VERSION
> 
> This patch is still RFC; if you like it, it's probably better to
> rebase portions of this patch into the rest of the series, rather
> than churning NBDKIT_API_VERSION temporarily to 2 and now back to 1
I do wonder if this patch is really worthwhile.  Old nbdkit / new
plugin is probably going to go untested in general, and therefore will
just cause problems/complexity.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

On 03/20/2018 05:00 AM, Richard W.M. Jones wrote:
> On Thu, Mar 08, 2018 at 05:03:11PM -0600, Eric Blake wrote:
>> If we bump NBDKIT_API_VERSION, we have forcefully made older
>> nbdkit reject all plugins that opt to the newer API:
>>
>> $ nbdkit ./plugins/nbd/.libs/nbdkit-nbd-plugin.so --dump-plugin
>> nbdkit: ./plugins/nbd/.libs/nbdkit-nbd-plugin.so: plugin is
incompatible with this version of nbdkit (_api_version = 2)
>>
>> But with a bit of finesse, we can make opting in to FUA support
>> orthogonal to NBDKIT_API_VERSION, by introducing a new witness
>> level that the user controls, and by providing sane fallbacks
>> so that newer plugins correctly populate the fields expected by
>> older nbdkit.
>>
>> ---
>> v3: rework entirely, add new variable instead of NBDKIT_API_VERSION
>>
>> This patch is still RFC; if you like it, it's probably better to
>> rebase portions of this patch into the rest of the series, rather
>> than churning NBDKIT_API_VERSION temporarily to 2 and now back to 1
> 
> I do wonder if this patch is really worthwhile.  Old nbdkit / new
> plugin is probably going to go untested in general, and therefore will
> just cause problems/complexity.
Fair enough. I'm happy to drop it (I had a tough enough time figuring 
out how to test it; my initial gut feel was that an old server + new 
plugin.so would die with an assertion failure when the old server 
asserted that .pread was non-NULL, and I was actually pleasantly 
surprised that the failure was graceful due to the incompatible version 
check that occurred prior to the .pread assertion.  Keeping a graceful 
failure is acceptable; I would have been pushing for something like this 
a lot harder if it had actually caused assertion failures).

New nbdkit / old plugin gets plenty of testing (most of our plugins 
still use the old interface, where only a few opt in to the new one, and 
since the testsuite still passes, we've proven that both interfaces are 
acceptable to the new binary).

So I'll go ahead and push 1-14, and then see if I can start playing with 
ways to expose FUA flags through the language bindings (I'll probably 
attempt python first).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

On Tue, Mar 20, 2018 at 08:45:13AM -0500, Eric Blake
wrote:
> So I'll go ahead and push 1-14, and then see if I can start playing
> with ways to expose FUA flags through the language bindings (I'll
> probably attempt python first).
Shall I do a new release after these are pushed, or wait for
the language bindings to be done?

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 Tue, Mar 20, 2018 at 08:45:13AM -0500, Eric Blake
wrote:
> So I'll go ahead and push 1-14, and then see if I can start playing
> with ways to expose FUA flags through the language bindings (I'll
> probably attempt python first).
Also .. I believe all the non-C languages we support have optional/
labelled parameters, so that seems like the natural way to express it.

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/