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

[Markus Armbruster]

Eric Blake <address@hidden> 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?