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

[Anthony Liguori <anthony@codemonkey.ws>]

On 12/16/2011 08:18 AM, Kevin Wolf wrote:
> 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).

What you're describing is what a link<> is.  Whenever you want the ability to 
make a choice (including the choice of None), a link<> is the type of property 
to use.

But too much choice can be a bad thing.  In many cases, you just want to have a 
child device for the purposes code sharing.  An ISA serial device embedding a 
UART is a good example of this.

Yes, you could make a UARTInterface and have the ISA serial device expose a 
link<UARTInterface> but that's roughly equivalent to having every chip on your 
motherboard be connected with a DIP package instead of being soldered on the 
board.  You could do it, but it would be very expensive and cumbersome.

> 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?

Yes.  I'm not terribly sure how this would work yet.  A link and a child 
property both acquire references to a device and release a reference to a device 
at destruction time.

For a child property, the reference held by the parent is the only reference in 
existing.  For non-child properties, the 'peripheral' container also holds a 
reference (since you want to be able to assign the device somewhere else in the 
device model).

I'm not sure tying life cycles for a user created device makes sense.  If a user 
creates a device, IMO, the user should be the one to destroy the device.

Regards,

Anthony Liguori

>
> Kevin
>