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