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