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

[Kevin Wolf <kwolf@redhat.com>]

Am 16.12.2011 14:51, schrieb Anthony Liguori:
> On 12/16/2011 06:24 AM, Paolo Bonzini wrote:
>> 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. :)
>>
>> 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).
> 
> What I would like to get to eventually is:
> 
> struct ISASerial {
>     Device parent;
> 
>     UART _child uart;
>     ISABus _link *bus;
> };
> 
> A child should be able to be part of the parent devices memory with its life 
> cycle bound to the parents life cycle.  This is why a child property shouldn't 
> be nullable.

I don't think being bound to the life cycle (that is, from realize on)
implies anything about being nullable.

For example, imagine two different types of UARTs with a compatible
interface, and you could choose whether to have one or the other on the
board. Maybe you could even use none at all (probably doesn't make a lot
of sense in this example, but I figure it might in other contexts).

So even though once the device is realized, the UART is bound to the
life cycle of your ISASerial, you wouldn't want to have the UART type
hard-coded, but leave the user a choice. Would this be modelled as a
link rather than a child?

Kevin