Re: [Qemu-devel] QOM vs QAPI for QMP APIs

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2047 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]