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<aligu...@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.
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
