From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:60683)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Sz5uI-0001aJ-J6
	for qemu-devel@nongnu.org; Wed, 08 Aug 2012 09:02:39 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Sz5uC-00068A-4u
	for qemu-devel@nongnu.org; Wed, 08 Aug 2012 09:02:38 -0400
Received: from mx1.redhat.com ([209.132.183.28]:26764)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Sz5uB-00067y-Pd
	for qemu-devel@nongnu.org; Wed, 08 Aug 2012 09:02:32 -0400
Message-ID: <50226361.8090006@redhat.com>
Date: Wed, 08 Aug 2012 15:02:25 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <50225901.7040101@msgid.tls.msk.ru>
	<50225A21.6070208@msgid.tls.msk.ru>
	<50225DEF.1060206@redhat.com> <50226006.6050402@suse.de>
In-Reply-To: <50226006.6050402@suse.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] commit da57febfed "qdev: give all devices a
 canonical path" broke usb_del
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= <afaerber@suse.de>
Cc: Peter Maydell <peter.maydell@linaro.org>, Anthony Liguori <aliguori@us.ibm.com>, Michael Tokarev <mjt@tls.msk.ru>, qemu-devel <qemu-devel@nongnu.org>

Il 08/08/2012 14:48, Andreas F=C3=A4rber ha scritto:
> Adding object_unparent() to object_delete() looks okay to me, but we
> should not forget about the upcoming i440fx and prep_pci use cases wher=
e
> we want to embed children in the parent's struct, so that
> object_delete() will never be called on it. Thus object_unparent() woul=
d
> need to remain present in the deinit path, no?

object_property_del_all should take care of it for embedded objects:
- the outermost struct is deleted via object_delete
- it is unparented and unrefed, so refcount goes to 0 and finalize is cal=
led
- finalize calls object_property_del_all
- object_finalize_child_property calls unref on the nested object, so
refcount goes to 0 and finalize is called.  Things can then proceed
recursively.

It would be more complicated (and would cause memory leaks) if you got
nested objects that were allocated.  To account for this, I understood
you would need something like the following:

- you add a "void (*release)(void *obj)" member to Object.
- object_new sets the release member to g_free
- object_delete does not call g_free anymore
- object_finalize calls the release member if it is not NULL

Do you have time to implement it?

Paolo