Eric Blake <ebl...@redhat.com> writes: > 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.
You didn't spell out the ABI promises here. Do you argue for providing QOM interfaces as unstable low-level interfaces?
