Re: [Qemu-devel] [PATCH v2 15/18] rtc: add a dynamic property for retrieving the date

[Anthony Liguori <anthony@codemonkey.ws>]

On 12/09/2011 08:04 AM, Kevin Wolf wrote:
> Am 09.12.2011 14:08, schrieb Anthony Liguori:
>> On 12/09/2011 05:26 AM, Kevin Wolf wrote:
>>> Am 02.12.2011 21:20, schrieb Anthony Liguori:
>>>> This really shows the power of dynamic object properties compared to qdev
>>>> static properties.
>>>>
>>>> This property represents a complex structure who's format is preserved over the
>>>> wire.  This is enabled by visitors.
>>>>
>>>> It also shows an entirely synthetic property that is not tied to device state.
>>>>
>>>> Signed-off-by: Anthony Liguori<aliguori@us.ibm.com>
>>>
>>> There's one thing that I was hoping to find answered when I would have
>>> reviewed the whole series, but it hasn't happened: There is no doubt
>>> that dynamic properties (in the sense of being able to modify them after
>>> constructions) are a useful thing. But you also claim that class-based
>>> properties are not enough for QOM and that we need object-based ones,
>>> which is a requirement not immediately obvious to me.
>>>
>>> Can you provide some examples where we would explicitly need
>>> object-based properties?
>>
>> Sure.  Any property that's dynamic needs to be object based.  A good example
>> would be PCI slots.
>>
>> Today, we unconditionally advertise 32 slots in our ACPI tables.  It could be
>> desirable to eventually make this configurable.  So you can imagine where you
>> would have an 'slot-count' property and if that was set to 16, it would result
>> in 'slot[0]..slot[15]' being created.
>>
>> There are other good examples too.
>
> So is it mostly about variably sized arrays, which just happen to be
> considered independent properties in your approach? Or are there cases
> where a logically separate property may be there or missing depending on
> some condition, or possibly even that a new property is created during
> runtime?

So there are three possibilities for properties:

1) Properties have no per-object state, and exist entirely within the classes. 
This is what qdev does today.

2) Properties are defined in the class, but carry per-object state.

3) Properties are defined in the object and carry per-object state.

We definitely can rule out (1).  Stateful properties are needed to implement 
links, composition, and just about anything interesting.

Another way that (3) is useful is that it allows you to create container devices 
that more or less model a PCB.  That's how peripheral[-anon] is implemented and 
I imagine that it will also be useful for implementing "machine" devices.

Of course, you could find a way to special case this with (2) but that's why I 
ended up going with (3).  You can avoid having a lot of special cases this way.

Regards,

Anthony Liguori

>
> Kevin
>