[Libguestfs] [nbdkit PATCH v2 3/5] python: Update internals to plugin API level 2

Eric Blake eblake at redhat.com
Thu Apr 19 18:16:28 UTC 2018


On 04/19/2018 12:26 PM, Richard W.M. Jones wrote:
> On Wed, Apr 11, 2018 at 12:03:40AM -0500, Eric Blake wrote:
>> Adjust internal functions in preparation for FUA support; although
>> at this point, the default plugins.c can_fua implementation
>> correctly reports python as needing emulation, and we can assert
>> that we aren't seeing a FUA flag.
>>
>> Signed-off-by: Eric Blake <eblake at redhat.com>
>> ---
>>  plugins/python/python.c | 17 ++++++++++++-----
>>  1 file changed, 12 insertions(+), 5 deletions(-)
>>

>>  static int
>>  py_pread (void *handle, void *buf,
>> -          uint32_t count, uint64_t offset)
>> +          uint32_t count, uint64_t offset, uint32_t flags)
>>  {
>>    PyObject *obj = handle;
>>    PyObject *fn;
>>    PyObject *r;
>>
>> +  assert (!flags);
> 
> I'm confused by the assertions here (I understand that these are
> relaxed in the next patch, but still present).
> 
> Shouldn't this return an error instead of segfaulting the daemon?

If the daemon passes us a flag we don't know how to handle, that's a bug
in the daemon and should cause an assert (we can't tell if the flag
would require us to support semantics we are unprepared for).  That is,
in order to abide by our C ABI back-compat rules, a newer daemon can
support newer flags, but in doing so, must NOT hand those flags to an
older plugin; nbdkit-plugin.pod even guarantees the condition under
which flags will be passed to the plugin (where violating those
guarantees is a bug in the daemon, not the plugin); the filters are
under similar rules to follow the same rules as the daemon about which
flags are safe to pass.

> 
> Do we assume that the nbdkit python plugin is special because you're
> basically always running the version that ships with the daemon?

No, you can run a newer nbdkit with an older python plugin without
issues, again, because the burden is on the daemon and not on the
plugin, when it comes to not handing unexpected flags to the plugin.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20180419/704859e8/attachment.sig>


More information about the Libguestfs mailing list