From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54458) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aifCv-00033S-8E for qemu-devel@nongnu.org; Wed, 23 Mar 2016 05:36:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aifCr-0005mq-7X for qemu-devel@nongnu.org; Wed, 23 Mar 2016 05:36:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51424) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aifCr-0005mZ-2h for qemu-devel@nongnu.org; Wed, 23 Mar 2016 05:36:01 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 942C1C049D7F for ; Wed, 23 Mar 2016 09:36:00 +0000 (UTC) References: <1456151945-11225-1-git-send-email-pbonzini@redhat.com> <1456151945-11225-2-git-send-email-pbonzini@redhat.com> <87a8lr27b7.fsf@blackfin.pond.sub.org> <56F013EF.1000401@redhat.com> <8737rj7npp.fsf@blackfin.pond.sub.org> <56F02F9B.9040305@redhat.com> <87h9fxd21w.fsf@blackfin.pond.sub.org> From: Paolo Bonzini Message-ID: <56F2637D.3070701@redhat.com> Date: Wed, 23 Mar 2016 10:35:57 +0100 MIME-Version: 1.0 In-Reply-To: <87h9fxd21w.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/3] block: detach devices from DriveInfo at unrealize time List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Kevin Wolf , qemu-devel@nongnu.org, Max Reitz On 23/03/2016 09:35, Markus Armbruster wrote: >> by that time you don't have anymore a QOM path to include in the event. > > I see. To delay DEVICE_DELETED, we'd have to save the QOM path, and > that would be bothersome. Not just that, the QOM path goes away at the time we currently raise DEVICE_DELETED. If we delay it to finalization, it might even have been reused. > Still, copying code from property to devices with that property is > undesirable. It's not that bad in this patch, because we copy only to > the devices that do warty backend deletion, and that's just the two > places where we call blockdev_mark_auto_del() now. However, it gets > worse if we decide to extend warty backend deletion to *all* devices: > more places, and a new need to consistently copy it to every new user of > the drive property. > > When you find yourself copying code from a property callback into every > device using it, the real problem might be you're missing a callback. > In this case, one that runs at unrealize time. The existing release() > runs at finalize time. That's certainly a good thing to do if we decide to extend autodeletion to the NVMe and SD devices. Paolo