Re: [Qemu-devel] KVM call minutes for Feb 8

[Markus Armbruster]

Anthony Liguori <address@hidden> writes:

> On 02/09/2011 02:01 AM, Markus Armbruster wrote:
>> Anthony Liguori<address@hidden>  writes:
[...]
>>> We need to unify the property model.  We have QemuOpts, qdev
>>> properties, and QObject which basically reinvents variant typing three
>>> different ways.
>>>      
>> Make it four: QEMUOptionParameter.
>>
>> Now let me make it three again.  Unlike the others, a qdev property
>> describes a perfectly ordinary, non-variant struct member.  It's poor
>> man's reflection, not a variant type.
>>    
>
> Except that construction of a device requires initialization from an
> array of variants (which is then type checked).  The way we store the
> variants is lossy because we convert back and forth to a string.

Yes, there's overlap, but no, a qdev property isn't yet another variant
type scheme.  Exhibit A of the defense: qdev uses QemuOpts for variant
types.

Let me elaborate.  qdev_device_add() uses QemuOpts as map from name to
variant type value, uses the name to look up the property, then uses
property methods to stuff the variant value it got from QemuOpts into
the (non-variant) struct member described by the property.

I figure QemuOpts was adopted for this purpose because it was already in
use with command line and human monitor.  With QMP added to the mix,
there's friction: QMP uses QDict, not QemuOpts.