[Libguestfs] [PATCH nbdkit v2 03/10] python: Implement nbdkit API version 2.
Eric Blake
eblake at redhat.com
Fri Nov 22 21:35:47 UTC 2019
On 11/22/19 3:20 PM, Nir Soffer wrote:
>>> +# There are several variants of the API. nbdkit will call this
>>> +# function first to determine which one you want to use. This is the
>>> +# latest version at the time this example was written.
>>> +def api_version():
>>> + return 2
>>
>> Matches the C counterpart of #define NBDKIT_API_VERSION 2 at the top of
>> a plugin.
>
> This is the same thing I was thinking about. This makes it more clear
> that the api
> version is constant, and not something the plugin should change while
> it is being used.
Hmm - api_version() really is constant for the entire life of nbdkit. We
call it exactly once. Figuring out how to read a Python variable
instead of calling a function would be slightly more in line with the
fact that in C code it is a #define constant rather than a function
pointer callback. But it is that much more glue code to figure out how
to check for a python global variable, compared to the glue code we
already have for calling a python function.
>
> Same for all can_xxx functions, NBD does not support changing any of
> these anyway
> after negotiation.
While can_xxx functions are somewhat dynamic (we only call them once per
connection, but connection A can be readonly while connection B is
read-write, changing the can_write result, for example). So those have
to remain functions.
>> and for zero (once fast zero is supported later in the series), it could
>> look like:
>>
>> def zero(h, count, offset, may_trim=False, fua=False, fast=False):
>
> This is nicer - but not extensible.
Why not? Any future flag additions would still appear as new key=value
kwargs.
>
>> The user could also write:
>>
>> def zero(h, count, offset, **flags)
>
> This is less nice, but easy to extend without adding v3. But I would
> call it **options
> instead.
I really need to post my patches where I played with kwargs, for
contrast to this version.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
More information about the Libguestfs
mailing list