From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58783) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbZBY-0002Gr-4T for qemu-devel@nongnu.org; Fri, 16 Dec 2011 09:55:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbZBR-00056y-OA for qemu-devel@nongnu.org; Fri, 16 Dec 2011 09:54:56 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:48725) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbZBR-00056U-L8 for qemu-devel@nongnu.org; Fri, 16 Dec 2011 09:54:49 -0500 Received: by iagj37 with SMTP id j37so5089346iag.4 for ; Fri, 16 Dec 2011 06:54:48 -0800 (PST) Message-ID: <4EEB5BB3.4030105@codemonkey.ws> Date: Fri, 16 Dec 2011 08:54:43 -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> <4EEB4CD1.7050701@us.ibm.com> <4EEB5337.1060800@redhat.com> In-Reply-To: <4EEB5337.1060800@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 , Stefan Hajnoczi , Jan Kiszka , qemu-devel@nongnu.org, Luiz Capitulino , Paolo Bonzini , Markus Armbruster On 12/16/2011 08:18 AM, Kevin Wolf wrote: > Am 16.12.2011 14:51, schrieb Anthony Liguori: >> On 12/16/2011 06:24 AM, Paolo Bonzini wrote: >>> On 12/16/2011 11:36 AM, Kevin Wolf wrote: >>>>> I think actually this is not the biggest problem. child properties are >>>>> dynamic, and it's not a problem IMO if they are created like that. >>>> >>>> That they are added in an init function is an indicator that they aren't >>>> really dynamic. >>> >>> That's true. However, another indicator is that anything that does not have a >>> struct field is also not really static. :) >>> >>> So right now, child properties are all "dynamic" in this sense. This could >>> change when Anthony converts buses to QOM. The bus right now is embedded into >>> the HBA's struct, is not a pointer. This likely would change when buses are >>> QOM-ized, but then the bus would indeed be a 100% static child. >>> >>>> I think having a child property that can be NULL could be >>>> reasonable. >>> >>> 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). >> >> 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. > 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. Regards, Anthony Liguori > > Kevin >