[Libguestfs] [PATCH libnbd] api: nbd_get_version, nbd_supports_uri and nbd_get_package_name.

[Eric Blake]

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

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