From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38068) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbYZZ-00057g-N5 for qemu-devel@nongnu.org; Fri, 16 Dec 2011 09:15:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbYZK-0005ke-83 for qemu-devel@nongnu.org; Fri, 16 Dec 2011 09:15:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:29689) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbYZJ-0005fF-9Z for qemu-devel@nongnu.org; Fri, 16 Dec 2011 09:15:25 -0500 Message-ID: <4EEB5337.1060800@redhat.com> Date: Fri, 16 Dec 2011 15:18:31 +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> In-Reply-To: <4EEB4CD1.7050701@us.ibm.com> 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 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). 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? Kevin