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

[Kevin Wolf <kwolf@redhat.com>]

Am 21.03.2016 um 19:14 hat Markus Armbruster geschrieben:
> 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.

While we're dreaming up things... Imagine a future where users don't
have to know about BlockBackend, but devices automatically create their
BlockBackend. Which happens to be something that I'd really like to have
and at least I haven't seen the show stopper for it yet. Which might
just be because we never really looked much into the details, but
anyway...

In this case, the relationship between DriveInfo and BlockBackend
couldn't be "BB owns DriveInfo" any more, because the BB would be
created later than the DriveInfo. (DriveInfo controls the creation of
the guest device which would create the BB during its initialisation.)

By the way, what's the reason again for keeping DriveInfo around even
after having created the guest device?

Kevin