qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 3/3] block: remove legacy_dinfo at blk_detach_dev time
Date: Mon, 21 Mar 2016 18:34:43 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]