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

[Paolo Bonzini <pbonzini@redhat.com>]

On 12/16/2011 01:55 PM, Kevin Wolf wrote:
> I don't think that not remembering the child device because you don't
> need to reference it any more makes it any less static. You could easily
> add the struct member, assign it once and then it matches your
> definition of static.

I think in that case you would add a link property, not a child.

> And it's not even true of all child devices, for example PCII440FXState
> does have a pointer to its piix3 already.

It's unused, actually.  You're right, even though I'm not sure whether a 
child<Pin> will be stored in the parent as a Pin or as a qemu_irq.

> >  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).
>
> So child properties are never configurable, and if a device is optional
> or you can choose between multiple devices then it should be a link
> instead. That is, device composition in term of "child devices" happens
> only hard-coded and the user doesn't do it.
>
> Is this a reasonably accurate description of the intention?

It does sound accurate.  In addition, a child property should really 
model a parent-child relationship and should create a tree.

As an example, say you want to join two devices ("A" and "B"), by adding 
a connection from B to A.  Assuming you cannot simply add A as a 
child<A> to B, you can do it in several ways:

1) directly add a link<A> property to B.

    Examples:

    - a local APIC has a link<CPUX86State>

2) generalizing (1), you can add a link<X> property to B, where X can be 
any superclass of A or an interface implemented by A.

    Examples:

    - an object representing a PCI bus has a link<PCIDevice> for each
      slot (PCIDevice is an abstract class)

    - a SCSIBus can have a link<SCSIBusAdapter> to the parent (assuming
      SCSIBus is a class and SCSIBusAdapter is an interface)

3) using composition ("has-a") instead of inheritance, you can add a 
child<X> property to A and a link<X> property to B.

     Example:

     - a SCSI bus adapter is a device that has a child<SCSIBus>.
       A SCSIDevice doesn't have a link to the adapter, but only
       a link<SCSIBus>.

     - instead of representing PCIDevice as a class, you could have a
       child<PCIConnector> in the children, and a link<PCIConnector> in
       the bus.  (I would actually prefer this to an abstract PCIDevice
       class, but we agreed that it would be too much churn for now).

     - X can be simply a "Pin".

     All of these examples match your definition, I tihnk.

For bidirectional links you can have any combination of the above.

Paolo