On Tue, Aug 30, 2022 at 01:16:02PM +0200, Laszlo Ersek wrote:
Thanks for the explanation. I didn't expect these two principles
to have
driven the design (generability, and long-term convenience calls). I
think the more usual (albeit likely less programmer-friendly) approach
is to (a) expose the minute details and let the end-programmer deal with
them, (b) let people write / maintain other-than-C language wrappers
manually.
The trouble with this is that maintaining the non-C language wrappers
becomes a huge amount of work that is constantly behind (see also:
libvirt). Generating bindings means less work and more utility for
everyone.
The down-side is that the bindings may not be completely natural in
all cases in all languages and there's a bit of a lowest common
denominator effect. Despite this, the non-C bindings are still pretty
good for libnbd.
>> - NBD_OPT_INFO in particular looks like a useless opcode.
>
> Useless when you already know what export you want to connect to. But
> useful during the 'nbdinfo' app when you want to learn as much as
> possible about every export exposed by a single nbd server, while
> still remaining in negotiation after each export thus queried.
Such "discovery" looks useful for humans, but is it useful to client
programs other than nbdinfo?
Maybe in practice everyone is going to use nbdinfo :-) but it's still
useful to have a way to query what exports are available. (Same for
metadata contexts.)
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v