From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54239) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ai3j7-0003Bn-6j for qemu-devel@nongnu.org; Mon, 21 Mar 2016 13:34:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ai3j6-0002xv-9I for qemu-devel@nongnu.org; Mon, 21 Mar 2016 13:34:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59740) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ai3j6-0002xp-3J for qemu-devel@nongnu.org; Mon, 21 Mar 2016 13:34:48 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id B07A851D for ; Mon, 21 Mar 2016 17:34:47 +0000 (UTC) References: <1456151945-11225-1-git-send-email-pbonzini@redhat.com> <1456151945-11225-4-git-send-email-pbonzini@redhat.com> <87k2kvzu0z.fsf@blackfin.pond.sub.org> <56F01F8A.2090902@redhat.com> <87shzj68n2.fsf@blackfin.pond.sub.org> From: Paolo Bonzini Message-ID: <56F030B3.3070709@redhat.com> Date: Mon, 21 Mar 2016 18:34:43 +0100 MIME-Version: 1.0 In-Reply-To: <87shzj68n2.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/3] block: remove legacy_dinfo at blk_detach_dev 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 21/03/2016 18:30, Markus Armbruster wrote: > However, I've now tested my expectation, and it turned out to be wrong. > I'm inclined to call that a bug. --verbose, what is wrong and what was your expectation? > > In other words, you said "This looks like DriveInfo now owns a reference > > to BlockBackend, even though the pointer still goes in the other > > direction". I say, "I thought this was the idea all along"... > > For me, the DriveInfo doesn't own anything, but a BlockBackend may have > a DriveInfo. Evidence: > > * The pointer goes from the BlockBackend to the DriveInfo > > * To go back, you search the blk_backends for the one that has the > DriveInfo. See blk_by_legacy_dinfo(). > > * There is no list of DriveInfo. If you want to find one, you search > blk_backends. See drive_get() & friends. That's from the point of view of the code. But from the point of view of the user, he specifies a drive=... and the device converts that under the hood to a BlockBackend; and when he calls drive_del on an unassigned drive, the BlockBackend is destroyed. There is no action on a BlockBackend that destroys the DriveInfo---except auto-deletion on unplug, but even then the user in the first place had provided a DriveInfo. So from the point of view of the user it's always been the DriveInfo that owned a BlockBackend. The lack of a list of DriveInfo is just an implementation detail. Paolo