From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33825) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ypf5c-0007cU-7W for qemu-devel@nongnu.org; Tue, 05 May 2015 11:49:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ypf5V-0007OD-V2 for qemu-devel@nongnu.org; Tue, 05 May 2015 11:48:56 -0400 Received: from e9.ny.us.ibm.com ([32.97.182.139]:41641) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ypf5V-0007Nj-QS for qemu-devel@nongnu.org; Tue, 05 May 2015 11:48:49 -0400 Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 5 May 2015 11:48:48 -0400 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: Michael Roth In-Reply-To: <55473D4F.2090901@redhat.com> References: <1430335224-6716-1-git-send-email-mdroth@linux.vnet.ibm.com> <1430335224-6716-3-git-send-email-mdroth@linux.vnet.ibm.com> <55422F91.4050504@redhat.com> <20150430230331.11253.37707@loki> <5543E581.9000809@redhat.com> <20150501225407.24247.3106@loki> <55473D4F.2090901@redhat.com> Message-ID: <20150505154843.25451.27981@loki> Date: Tue, 05 May 2015 10:48:43 -0500 Subject: Re: [Qemu-devel] [RFC PATCH 02/15] qdev: store DeviceState's canonical path to use when unparenting List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , qemu-devel@nongnu.org Cc: "Michael S. Tsirkin" , aik@ozlabs.ru, qemu-ppc@nongnu.org, bharata@linux.vnet.ibm.com, nfont@linux.vnet.ibm.com, david@gibson.dropbear.id.au Quoting Paolo Bonzini (2015-05-04 04:35:11) > = > = > On 02/05/2015 00:54, Michael Roth wrote: > >> > = > >> > What about unparenting children devices in the device's unrealize > >> > callback? It sucks that you have to do it manually, but using stale > >> > canonical paths isn't the nicest thing either. > > That does seems to do the trick. It felt wrong when I first looked at > > it because in some cases the children attach themselves to the parent > > without making making the parent aware, > = > Can you point to an example? The parent "owns" its property namespace, > so it would be wrong for a child to attach itself unbeknownst to the pare= nt. Well, I was referring to: sPAPRTCETable *spapr_tce_new_table(DeviceState *owner, uint32_t liobn) and: sPAPRDRConnector *spapr_dr_connector_new(Object *owner, sPAPRDRConnectorType type, uint32_t id) It wasn't immediately obvious to me that this would result in the resulting objects attaching themselves as children, but in retrospect that does seem to be implied by the 'owner' parameter. If there are cases where this is done with a parameter that isn't explicitly named 'owner' though it might be somewhat ambiguous (could be pulling out individual fields as opposed to attaching itself), but I don't see any examples outside of local functions or qdev-managed devices. > = > There are a couple cases where an object adds a property to another > object, e.g. the rtc-time property of /machine, but in that case the > property is a well-known name whose setting is "outsourced" by /machine > to the device. > = > Paolo >=20