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
