Re: [Qemu-devel] [PATCH 3/3] block: remove legacy_dinfo at blk_detach_dev time

From: Markus Armbruster <armbru@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 3/3] block: remove legacy_dinfo at blk_detach_dev time
Date: Mon, 21 Mar 2016 19:14:22 +0100	[thread overview]
Message-ID: <87fuvj1ywx.fsf@blackfin.pond.sub.org> (raw)
In-Reply-To: <56F030B3.3070709@redhat.com> (Paolo Bonzini's message of "Mon, 21 Mar 2016 18:34:43 +0100")

Paolo Bonzini <pbonzini@redhat.com> writes:

> 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?

x-blockdev-del should refuse to touch anything not created with
blockdev-add.

>> > 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.

>From the user's point of view, neither BlockBackend nor DriveInfo are
visible :)

A BlockBackend may have a DriveInfo.  If it has one, then destroying the
BlockBackend also destroys its DriveInfo.

DriveInfo exists only to capture a -drive in a more convenient form than
its QemuOpts.  We use it for creating a BlockBackend.  It lives on after
that only because -drive mixes up front- and backend matter.  Keeping
DriveInfo around hanging off BlockBackend lets us keep frontend matter
out of BlockBackend: if need to access mixed up frontend matter for
back-compat, we find it in the BlockBackend's DriveInfo.

Imagine a future where we drop -drive / drive_add, or at least its mixed
up aspects (doesn't have to be practical for imagining it).  In that
future, we'd also drop DriveInfo.