From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47662) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T60XN-0006Z5-Oi for qemu-devel@nongnu.org; Mon, 27 Aug 2012 10:44:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T60XB-0007Ky-1o for qemu-devel@nongnu.org; Mon, 27 Aug 2012 10:43:33 -0400 Received: from cantor2.suse.de ([195.135.220.15]:33499 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T60XA-0007Jq-O5 for qemu-devel@nongnu.org; Mon, 27 Aug 2012 10:43:20 -0400 Message-ID: <503B8783.1040809@suse.de> Date: Mon, 27 Aug 2012 16:43:15 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1345996298-4892-1-git-send-email-aliguori@us.ibm.com> <1345996298-4892-4-git-send-email-aliguori@us.ibm.com> <503B7E11.6050009@suse.de> <873938l8iy.fsf@codemonkey.ws> In-Reply-To: <873938l8iy.fsf@codemonkey.ws> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 3/9] qbus: remove glib_allocated/qom_allocated and use release hook to free memory List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Paolo Bonzini , Liu Ping Fan , qemu-devel@nongnu.org Am 27.08.2012 16:22, schrieb Anthony Liguori: > Andreas F=C3=A4rber writes: >=20 >> I wonder how this is gonna work: The device used to be in charge of >> tearing down its bus children ... now it neither deletes nor finalizes >> nor unrefs? Is the while loop even still needed? >> >> Wouldn't the busses still have the device as parent, referencing it, >> blocking device_finalize? >=20 > This has never been right.. Just because a controller goes away, it > doesn't mean that the devices ought to go away too. >=20 > There are different types of "remove" so let's consider each. >=20 > 1) Guest visible eject: if a controller is ejected, then the guest will > obviously see everything behind it get removed too. This is an > emulation detail, not a QOM thing. >=20 > 2) Final deletion: this only happens when all references go away. If > you eject a controller but there are still children that reference > it, the controller won't go away. You actually need to delete each > individual disk (or whatever is behind it) in order to break the > reference counting. >=20 > The eject notifier could walk the full bus and attempt to break the > connections but honestly, I'd much prefer that we deprecate the current > device_del interface and just do everything through QOM properties. > That would mean manually deleting all of the devices behind the bus if > that's really what you wanted to do. I think we're talking about different scenarios here... I was thinking PCIHostState has-a PCIBus (not PCIBus has-a PCIDevice) and final deletion. In that case I would expect that it must be guaranteed that the device that created the bus has access to the bus until it destroys it. But IIUC the PCIHostState, once unparented from its SysBus (bad example!), has a refcount of 1 (its PCIBus) thereby not being finalized? I do understand your concept of refcounting matches what Java, .NET, etc. do for objects but combined with the new QBus I feel this is blurring the encapsulations and expected semantics of the device-centric functions we have. To me the uninitfn means "the whole object goes away" and is incompatible with "part of its children may stay behind if there are still stray references to them"... we can no longer properly access them then, only devices have canonical paths, so we'd risk piling up garbage at runtime. Regards, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg