From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:40592)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <weidong.huang@huawei.com>) id 1XgRge-0002Ya-D6
	for qemu-devel@nongnu.org; Tue, 21 Oct 2014 01:09:25 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <weidong.huang@huawei.com>) id 1XgRg2-0006Eb-F2
	for qemu-devel@nongnu.org; Tue, 21 Oct 2014 01:08:48 -0400
Received: from szxga03-in.huawei.com ([119.145.14.66]:59758)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <weidong.huang@huawei.com>) id 1XgRg1-0006Cu-P2
	for qemu-devel@nongnu.org; Tue, 21 Oct 2014 01:08:10 -0400
Message-ID: <5445E9D2.20805@huawei.com>
Date: Tue, 21 Oct 2014 13:06:26 +0800
From: Weidong Huang <hwd@huawei.com>
MIME-Version: 1.0
References: <54423AC9.2030302@huawei.com>
	<20141020094149.GC3585@noname.redhat.com>
	<5444F1B2.9090700@huawei.com>
	<87a94rndnb.fsf@blackfin.pond.sub.org>
In-Reply-To: <87a94rndnb.fsf@blackfin.pond.sub.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] Close the BlockDriverState when guest eject the
 media
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Markus Armbruster <armbru@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, stefanha@redhat.com

On 2014/10/20 20:12, Markus Armbruster wrote:

> 
> Correct.  This is a known wart.  To work around it, wait for event
> DEVICE_TRAY_MOVED and eject again.  Yes, this is racy: the guest can
> reclose the tray and lock it before you get your eject in.


Yes. You got it. But how to resolve the racy?
I intend to return fail in this situation. What's your opinion?

 
> Programs really depend on "eject, load, get the same medium back"
> behavior.  Example: https://bugzilla.redhat.com/show_bug.cgi?id=558256
>     
> We intend to provide new commands that behave better than "eject".
> Don't hold your breath.


Good news.

I think "eject" command should not to drop the media too. It just only open the
tray, and nothing else.

Calling bdrv_close() could be done in "change media" command. And "change media"
command also can remove the media by null path.

So this problem can be resolved. What do you think of it?

Thanks.