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 _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
