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

[Andreas Färber]

Am 25.02.2014 09:25, schrieb Markus Armbruster:
> Eric Blake <address@hidden> writes:
> 
>> 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.
> 
> My question isn't about where the command details are documented, or
> even whether they are documented.  It's about ABI promises, or lack
> thereof.  The general promise for QMP is we treat it as stable ABI.  If
> we add QMP commands to examine and manipulate QOM, doesn't that move all
> of QOM under the QMP ABI promise, unless we explicitly excempt it?

Anthony has clearly stated and I have been repeating that QOM follows
strict ABI stability rules for its properties, and that therefore
applies to what some of you still call "qdev" as well. Therefore my
nagging to get underscores vs. dashes right for new properties and
questioning attempted type changes without changing the property name.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg