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

[Anthony Liguori]

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