On 02/24/2014 01:29 AM, Markus Armbruster wrote: >> >> The other burden is documenting what QOM paths to be queried, and >> knowing where to find that documentation. That is, it's another layer >> of complexity, but it's also a more powerful expression. >> >> I'm comparing this situation somewhat to libvirt's 'virsh >> qemu-monitor-command' vs. other libvirt commands. qemu-monitor-command >> is a more powerful interface (via libvirt, you can issue ANY qmp >> command), and is therefore great for development for testing something >> that libvirt has not yet supported; but not so nice to the end user >> (it's use is explicitly unsupported). What happens is that as people >> say "I had to use qemu-monitor-command to do task A", it is a hint to >> libvirt development to say "oh, we need to add an API to make task A >> easier to do". >> >> Thus, having qom-find-objects-by-class is a good idea, even if it is >> more awkward to use than a dedicated qmp command. But meanwhile, we >> should watch what common patterns it gets used for, and add dedicated >> QMP commands for those patterns. It's much faster to get a chunk of >> information in one QMP call already formatted into desired structs than >> it is to make a series of QMP calls to learn about the lower-level qom >> model one piece at a time. > > You didn't spell out the ABI promises here. Do you argue for providing > QOM interfaces as unstable low-level interfaces?
Haven't we already done that in the past? For example, object-add currently takes an unspecified dictionary of options, where you would have to consult QOM documentation to learn what makes sense to send. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
