On 6/3/19 4:59 AM, Richard W.M. Jones wrote:
nbd_get_version returns the library version as a string.
nbd_supports_uri returns whether or not the library was compiled with
NBD URI support (ie. with libxml2).
nbd_get_package_name is fairly useless as it always returns the string
"libnbd", however it replaces a function that was written for the
Python bindings.
These take a handle parameter but don't need to use it. Changing the
generator to support a whole new class of API calls which don't need a
handle is a massive pain.
Should we permit and/or document that these functions may pass NULL (at
least in C bindings) for the nbd_handle? (It's harder in other
languages, where you would treat it as more of a static method rather
than an instance method - hence I agree with your comment that
refactoring the generator to support that is harder)
Looks good to me.
I agree that supports_uri should be a runtime question. Having the
version as a runtime answer is sane enough (even if being a string
requires a bit of parsing to interpret the version). There's still the
question if additionally exposing the version as a compile-time constant
can also make it easier to conditionally use other API (such as
nbd_supports_uri) based on version-number checks for whether it is known
to be present (not as nice as a configure-check for the actual function,
in case it was backported across version numbers, but having
compile-time constants allows skipping the development of the
configure-time check).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization:
qemu.org |
libvirt.org