[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 15/18] rtc: add a dynamic property for retrie
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH v2 15/18] rtc: add a dynamic property for retrieving the date |
Date: |
Tue, 13 Dec 2011 10:27:05 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 |
Am 09.12.2011 15:25, schrieb Anthony Liguori:
> 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<address@hidden>
>>>>
>>>> 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.
Not quite sure what you mean by per-object state. The properties are
fields in the XyzState, so they certainly are per-object?
> 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.
What would this look like? The user creates new child/link properties on
the board, and some more automatically created properties somehow
describe the wiring between them?
> 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.
I'm not entirely convinced that we really need this, but on the other
hand I don't feel strong enough about it to argue.
Actually I think my real problem isn't about per-object properties
(although they might add unnecessary complexity), but more about going
away from the qdev style of things where you had _one_ struct definition
that nicely described all of the properties in a central place. Instead,
I'm seeing patches that spread property definitions all over the code.
Now I understand that for dynamically created properties (like on your
PCB) this is necessary and can't be avoided. For about 99% of the
devices static definition of properties would be enough, though.
So basically what I'm asking for is getting the static structs back for
the 99% and have common code that parses them and calls the appropriate
functions to actually the properties. The remaining 1% that
creates/deletes properties during runtime and isn't covered can directly
call whatever it needs.
Kevin
- [Qemu-devel] [PATCH v2 16/18] qom: optimize qdev_get_canonical_path using a parent link, (continued)
- [Qemu-devel] [PATCH v2 16/18] qom: optimize qdev_get_canonical_path using a parent link, Anthony Liguori, 2011/12/02
- [Qemu-devel] [PATCH v2 18/18] qom: add test tools (v2), Anthony Liguori, 2011/12/02
- [Qemu-devel] [PATCH v2 17/18] qmp: make qmp.py easier to use, Anthony Liguori, 2011/12/02
- [Qemu-devel] [PATCH v2 15/18] rtc: add a dynamic property for retrieving the date, Anthony Liguori, 2011/12/02
- Re: [Qemu-devel] [PATCH v2 15/18] rtc: add a dynamic property for retrieving the date, Kevin Wolf, 2011/12/09
- Re: [Qemu-devel] [PATCH v2 15/18] rtc: add a dynamic property for retrieving the date, Anthony Liguori, 2011/12/09
- Re: [Qemu-devel] [PATCH v2 15/18] rtc: add a dynamic property for retrieving the date, Kevin Wolf, 2011/12/09
- Re: [Qemu-devel] [PATCH v2 15/18] rtc: add a dynamic property for retrieving the date, Anthony Liguori, 2011/12/09
- Re: [Qemu-devel] [PATCH v2 15/18] rtc: add a dynamic property for retrieving the date,
Kevin Wolf <=
- Re: [Qemu-devel] [PATCH v2 15/18] rtc: add a dynamic property for retrieving the date, Gerd Hoffmann, 2011/12/13
- Re: [Qemu-devel] [PATCH v2 15/18] rtc: add a dynamic property for retrieving the date, Anthony Liguori, 2011/12/13
- Re: [Qemu-devel] [PATCH v2 15/18] rtc: add a dynamic property for retrieving the date, Anthony Liguori, 2011/12/13
- Re: [Qemu-devel] [PATCH v2 15/18] rtc: add a dynamic property for retrieving the date, Kevin Wolf, 2011/12/13
[Qemu-devel] [PATCH v2 11/18] qom: qom_{get, set} monitor commands (v2), Anthony Liguori, 2011/12/02