From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40350) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbZNi-0007FP-KV for qemu-devel@nongnu.org; Fri, 16 Dec 2011 10:07:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbZNc-0007l0-Us for qemu-devel@nongnu.org; Fri, 16 Dec 2011 10:07:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:64964) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbZNc-0007kt-OG for qemu-devel@nongnu.org; Fri, 16 Dec 2011 10:07:24 -0500 Message-ID: <4EEB5F60.6000200@redhat.com> Date: Fri, 16 Dec 2011 16:10:24 +0100 From: Kevin Wolf 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> <4EEB4CD1.7050701@us.ibm.com> <4EEB5337.1060800@redhat.com> <4EEB5BB3.4030105@codemonkey.ws> In-Reply-To: <4EEB5BB3.4030105@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 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: Anthony Liguori Cc: Peter Maydell , Stefan Hajnoczi , Jan Kiszka , qemu-devel@nongnu.org, Luiz Capitulino , Paolo Bonzini , Markus Armbruster Am 16.12.2011 15:54, schrieb Anthony Liguori: > On 12/16/2011 08:18 AM, Kevin Wolf wrote: >> Am 16.12.2011 14:51, schrieb Anthony Liguori: >>> What I would like to get to eventually is: >>> >>> struct ISASerial { >>> Device parent; >>> >>> UART _child uart; >>> ISABus _link *bus; >>> }; >>> >>> A child should be able to be part of the parent devices memory with its life >>> cycle bound to the parents life cycle. This is why a child property shouldn't >>> be nullable. >> >> I don't think being bound to the life cycle (that is, from realize on) >> implies anything about being nullable. >> >> For example, imagine two different types of UARTs with a compatible >> interface, and you could choose whether to have one or the other on the >> board. Maybe you could even use none at all (probably doesn't make a lot >> of sense in this example, but I figure it might in other contexts). > > What you're describing is what a link<> is. Whenever you want the ability to > make a choice (including the choice of None), a link<> is the type of property > to use. > > But too much choice can be a bad thing. In many cases, you just want to have a > child device for the purposes code sharing. An ISA serial device embedding a > UART is a good example of this. > > Yes, you could make a UARTInterface and have the ISA serial device expose a > link but that's roughly equivalent to having every chip on your > motherboard be connected with a DIP package instead of being soldered on the > board. You could do it, but it would be very expensive and cumbersome. Sure, I'm not saying it's a practical thing to do in this case, I just wanted to understand the way things are supposed to be modelled. I think I understand now when it should be a child and when a link. >> So even though once the device is realized, the UART is bound to the >> life cycle of your ISASerial, you wouldn't want to have the UART type >> hard-coded, but leave the user a choice. Would this be modelled as a >> link rather than a child? > > Yes. I'm not terribly sure how this would work yet. A link and a child > property both acquire references to a device and release a reference to a device > at destruction time. > > For a child property, the reference held by the parent is the only reference in > existing. For non-child properties, the 'peripheral' container also holds a > reference (since you want to be able to assign the device somewhere else in the > device model). > > I'm not sure tying life cycles for a user created device makes sense. If a user > creates a device, IMO, the user should be the one to destroy the device. Yes, that might be the most consistent. Kevin