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