From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36017) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbXqA-0002rI-QH for qemu-devel@nongnu.org; Fri, 16 Dec 2011 08:28:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbXq6-0005jk-Fz for qemu-devel@nongnu.org; Fri, 16 Dec 2011 08:28:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54130) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbXq6-0005je-9G for qemu-devel@nongnu.org; Fri, 16 Dec 2011 08:28:42 -0500 Message-ID: <4EEB4782.9090707@redhat.com> Date: Fri, 16 Dec 2011 14:28:34 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1323721784-704-1-git-send-email-aliguori@us.ibm.com> <4EEA3813.80006@us.ibm.com> <4EEB1277.4070803@redhat.com> <4EEB1ABB.50204@redhat.com> <4EEB1F3B.8070302@redhat.com> <4EEB3891.2020003@redhat.com> <4EEB3FA4.9010807@redhat.com> In-Reply-To: <4EEB3FA4.9010807@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 00/20] qom: dynamic properties and composition tree List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Peter Maydell , Anthony Liguori , Stefan Hajnoczi , Jan Kiszka , qemu-devel@nongnu.org, Luiz Capitulino , Markus Armbruster 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 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 to B, you can do it in several ways: 1) directly add a link property to B. Examples: - a local APIC has a link 2) generalizing (1), you can add a link 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 for each slot (PCIDevice is an abstract class) - a SCSIBus can have a link 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 property to A and a link property to B. Example: - a SCSI bus adapter is a device that has a child. A SCSIDevice doesn't have a link to the adapter, but only a link. - instead of representing PCIDevice as a class, you could have a child in the children, and a link 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