Re: [Qemu-devel] [PATCH v3 00/20] qom: dynamic properties and composition tree

[Kevin Wolf <kwolf@redhat.com>]

Am 16.12.2011 13:24, schrieb Paolo Bonzini:
> On 12/16/2011 11:36 AM, Kevin Wolf wrote:
>>>  I think actually this is not the biggest problem.  child properties are
>>>  dynamic, and it's not a problem IMO if they are created like that.
>>
>> That they are added in an init function is an indicator that they aren't
>> really dynamic.
> 
> That's true.  However, another indicator is that anything that does not 
> have a struct field is also not really static. :)

I don't think that not remembering the child device because you don't
need to reference it any more makes it any less static. You could easily
add the struct member, assign it once and then it matches your
definition of static.

And it's not even true of all child devices, for example PCII440FXState
does have a pointer to its piix3 already.

> So right now, child properties are all "dynamic" in this sense.  This 
> could change when Anthony converts buses to QOM.  The bus right now is 
> embedded into the HBA's struct, is not a pointer.  This likely would 
> change when buses are QOM-ized, but then the bus would indeed be a 100% 
> static child.
> 
>> I think having a child property that can be NULL could be
>> reasonable.
> 
> I think Anthony convinced me this is not the case (unlike links).  Even 
> if buses and similar objects are changed to pointers because the 
> implementation needs that, those pointers should never be NULL (or if 
> they can, the child property should not exist when they are NULL).

So child properties are never configurable, and if a device is optional
or you can choose between multiple devices then it should be a link
instead. That is, device composition in term of "child devices" happens
only hard-coded and the user doesn't do it.

Is this a reasonably accurate description of the intention?

Kevin