On 01/24/2018 08:18 AM, Richard W.M. Jones wrote:
> Note that even if we try hard to let newer nbdkit load an older
> filter (which I did not do here), we absolutely cannot let older
> nbdkit load a newer filter - while we have sizing limits to
> guarantee we don't call beyond the end of an older filter's
> smaller struct, there are no sizing limits in the other
> direction to prevent a newer filter to know that it cannot call
> beyond the end of our smaller nbdkit_next_ops.
Hmm, yes, this is a good point that I didn't think about.
Probably we're going to have to forget about the filter._api_version
and filter._struct_size fields and instead encode the version of
nbdkit it was compiled against and check that rigorously. It seems
like maintaining a filter ABI is hopeless.
About the only thing I could think of that MIGHT let us preserve ABI
from future filter to older nbdkit is if instead of using
next_ops.foo(), we add functions named next_foo(). nbdkit-filter.h
would then define weak-linkage functions that can only error out, but
which get overridden when available by strong linkage functions in
nbdkit proper. Then a newer filter run against an older nbdkit will
call the weak-linkage function and see a proper failure in trying to
call the next function, while a filter run against the current nbdkit
will call the strong-linkage variant that does the intended passthrough
to the next layer. But that's a lot of effort (and a one-time API
break) to set up something that will allow a stable ABI from that point
on, even if we didn't have the issue that running a newer plugin against
an older nbdkit may not be a reasonable goal (my FUA patches already
demonstrated that having new nbdkit run an old plugin is easy, but
having an old nbdkit run a new plugin may not work if the new plugin
only provides the new API callbacks and nbdkit-plugin.h doesn't provide
fallback shims in the old API callbacks).
As requested on 2/3, I'll factor out the ABI check into a separate
patch, and go with your suggestion that a simple version check is easier
than using a struct size check - which does indeed cement us into a
filter must be re-compiled in lockstep with nbdkit (we may still choose
to relax that later, but it's always better to start conservative).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization:
qemu.org |
libvirt.org