[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v3 00/20] qom: dynamic properties and composition tree
Date: Fri, 16 Dec 2011 14:28:34 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]