On 02/21/2014 07:37 AM, Paolo Bonzini wrote: >> I have no objection to introducing a QMP command. >> >> I think qom-find-objects-by-class is a reasonable approach but I would >> also consider just grouping all of the IOThreads in a well known path >> instead of just having them live in /objects. So something like >> /objects/threads/thread0/pid. > > /objects is the namespace for -object, but a similar idea is that > objects could create links of themselves under other paths. So you > would have /threads where you can list iothread objects or /backend/rng > for RNG backends. > > Still Stefan doesn't like the idea of sending O(n) commands to query the > thread ID of n iothread objects.
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. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
