From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbXGZ-0003ci-K0 for qemu-devel@nongnu.org; Fri, 16 Dec 2011 07:52:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbXGV-0007Cx-Ft for qemu-devel@nongnu.org; Fri, 16 Dec 2011 07:51:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59477) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbXGV-0007Ct-5R for qemu-devel@nongnu.org; Fri, 16 Dec 2011 07:51:55 -0500 Message-ID: <4EEB3FA4.9010807@redhat.com> Date: Fri, 16 Dec 2011 13:55:00 +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> In-Reply-To: <4EEB3891.2020003@redhat.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: Paolo Bonzini Cc: Peter Maydell , Anthony Liguori , Stefan Hajnoczi , Jan Kiszka , qemu-devel@nongnu.org, Luiz Capitulino , Markus Armbruster Am 16.12.2011 13:24, schrieb Paolo Bonzini: > 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. :) 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. And it's not even true of all child devices, for example PCII440FXState does have a pointer to its piix3 already. > 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). 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? Kevin