From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43648) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbYDX-00013t-Q6 for qemu-devel@nongnu.org; Fri, 16 Dec 2011 08:52:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbYDR-0001Pc-O7 for qemu-devel@nongnu.org; Fri, 16 Dec 2011 08:52:55 -0500 Received: from e35.co.us.ibm.com ([32.97.110.153]:46995) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbYDR-0001PY-59 for qemu-devel@nongnu.org; Fri, 16 Dec 2011 08:52:49 -0500 Received: from /spool/local by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 16 Dec 2011 06:52:47 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pBGDqTEU055634 for ; Fri, 16 Dec 2011 06:52:29 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pBGDqTnJ017552 for ; Fri, 16 Dec 2011 06:52:29 -0700 Message-ID: <4EEB4D1B.2000507@us.ibm.com> Date: Fri, 16 Dec 2011 07:52:27 -0600 From: Anthony Liguori 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> <4EEB4782.9090707@redhat.com> In-Reply-To: <4EEB4782.9090707@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: Paolo Bonzini Cc: Kevin Wolf , Peter Maydell , Stefan Hajnoczi , Jan Kiszka , qemu-devel@nongnu.org, Luiz Capitulino , Markus Armbruster On 12/16/2011 07:28 AM, Paolo Bonzini wrote: > 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. Yes, exactly. Regards, Anthony Liguori > > Paolo >