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

[Eric Blake]

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