From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41642) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4IzV-00059l-0U for qemu-devel@nongnu.org; Wed, 22 Aug 2012 18:01:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T4IzT-0003fT-RQ for qemu-devel@nongnu.org; Wed, 22 Aug 2012 18:01:32 -0400 Received: from mail-we0-f173.google.com ([74.125.82.173]:49446) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4IzT-0003fD-Js for qemu-devel@nongnu.org; Wed, 22 Aug 2012 18:01:31 -0400 Received: by weyz53 with SMTP id z53so38234wey.4 for ; Wed, 22 Aug 2012 15:01:30 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <503556B8.3040109@redhat.com> Date: Thu, 23 Aug 2012 00:01:28 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1345604562-27289-1-git-send-email-qemulist@gmail.com> <5034CA4C.7020706@redhat.com> <877gsqlw96.fsf@codemonkey.ws> <5035475A.5070409@redhat.com> <87628a4nb1.fsf@codemonkey.ws> In-Reply-To: <87628a4nb1.fsf@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] qom: removal of link property need to release its target List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Liu Ping Fan , Liu Ping Fan , qemu-devel@nongnu.org Il 22/08/2012 23:41, Anthony Liguori ha scritto: > > (1) should drop the floating reference and the reference held by the > container. That's what I meant by calling object_unparent in > qmp_device_del. > > (2) should simply remove the device from the bus (further releasing a > reference). > > (3) would happen automatically from (1) and (2) if they were called in > that order. > > If the guest instantiates a remove on it's own, the device would be > disconnected from the bus (functionally unplugged) but still in the > container so it would *not* go away. > > I think this is desirable behavior. It may be (I'm not sure it is desirable for HMP), but it's also backwards-incompatible. Right now, an unrequested guest-initiated remove causes the device to disappear in "info qtree" too. So, for backwards-compatibility we need to keep using object_delete after setting the parent bus to NULL. WRT adding the unparent *also* in qmp_device_del, that prevents you from later doing a surprise removal via the monitor, because you don't have anymore a way to refer the device. I'm also worried of what happens if an object loses its canonical path in the middle of its life... I'm not sure object_unparent should be extern, even. Paolo