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

[Kevin Wolf]

Am 16.12.2011 15:54, schrieb Anthony Liguori:
> On 12/16/2011 08:18 AM, Kevin Wolf wrote:
>> Am 16.12.2011 14:51, schrieb Anthony Liguori:
>>> 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.

Sure, I'm not saying it's a practical thing to do in this case, I just
wanted to understand the way things are supposed to be modelled. I think
I understand now when it should be a child and when a link.

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

Yes, that might be the most consistent.

Kevin