From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58542) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RtjBC-0006yI-Gj for qemu-devel@nongnu.org; Sat, 04 Feb 2012 12:13:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RtjBA-0001Ig-Tw for qemu-devel@nongnu.org; Sat, 04 Feb 2012 12:13:38 -0500 Received: from mail-pz0-f45.google.com ([209.85.210.45]:38279) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RtjBA-0001I7-PC for qemu-devel@nongnu.org; Sat, 04 Feb 2012 12:13:36 -0500 Received: by dadp14 with SMTP id p14so4727358dad.4 for ; Sat, 04 Feb 2012 09:13:35 -0800 (PST) Message-ID: <4F2D673B.3090605@codemonkey.ws> Date: Sat, 04 Feb 2012 11:13:31 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1328201142-26145-1-git-send-email-pbonzini@redhat.com> <1328201142-26145-2-git-send-email-pbonzini@redhat.com> <4F2BEED5.3050904@codemonkey.ws> <4F2C7B7B.60801@redhat.com> <4F2CA008.2040402@codemonkey.ws> <4F2CD561.3020100@redhat.com> In-Reply-To: <4F2CD561.3020100@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 01/16] qdev: fix hot-unplug List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org On 02/04/2012 12:51 AM, Paolo Bonzini wrote: > On 02/04/2012 04:03 AM, Anthony Liguori wrote: >> There's no object_ref() in qdev_device_add(). The 2 references come >> from adding a child link to /peripheral and via object_new(). > > Sure, but there's when the object_new() reference becomes unreachable. At this > point, if it weren't for /peripheral the device should have disappeared. > >> object_free() drops a reference (it's called in qdev_device_del()) and >> in the process of calling object_free(), it also calls object_unparent() >> which will drop the reference from the parent. >> >> I'm not thrilled about the way reference counting is done now. Perhaps >> we should do a gobject style floating reference... > > I'm not sure that's a problem. Rather, the problem is that we are (still) mixing > manual memory management and refcounting by making object_delete drop a reference. > > Can you remind me of why you have object_unref separate from object_delete? Is > it because you must not delete objects that were object_initialize'd rather than > object_new'd? Perhaps we can take care of that with a flag elsewhere saying "do > not free this object when object_unref drops the last ref" (only finalize it). I really didn't want to bake allocation into the type interface. I think there's another more robust way to handle this. We need signal support. I'd really like to have generic signals that showed up a signal<> property type, that could also be registered over QMP, but in the interim, we can probably just an ad-hoc NotifierList and do something better later. Anyway, we should have a "destroy" signal and a "delete" signal. destroy is fired when object_finalize() is called at the very beginning of the function. delete is fired at the very end of object_finalize(). We would change object_delete() to call object_unref and then object_finalize(). We would connect a "delete" event in object_new() that would free the memory. This would also allow object_property_add_child() to connect to the "destroy" event such that it could remove the reference it holds on the child. I'll work up a patch. I've got some ideas about how to do generic signals too but I'd prefer to wait to introduce all of that. Regards, Anthony Liguori > Thanks for analyzing the behavior. We don't have to get it right immediately as > long as we know what's going on, the transition is not complete anyway. > > Paolo >