From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34922) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgVap-00044a-4d for qemu-devel@nongnu.org; Tue, 21 Oct 2014 05:19:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XgVak-0007lQ-09 for qemu-devel@nongnu.org; Tue, 21 Oct 2014 05:19:03 -0400 Received: from szxga02-in.huawei.com ([119.145.14.65]:48602) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgVaj-0007ko-Ao for qemu-devel@nongnu.org; Tue, 21 Oct 2014 05:18:57 -0400 Message-ID: <544624C3.6080407@huawei.com> Date: Tue, 21 Oct 2014 17:17:55 +0800 From: Gonglei MIME-Version: 1.0 References: <54423AC9.2030302@huawei.com> <20141020094149.GC3585@noname.redhat.com> <5444F1B2.9090700@huawei.com> <87a94rndnb.fsf@blackfin.pond.sub.org> <5445E9D2.20805@huawei.com> <87lho9hlfd.fsf@blackfin.pond.sub.org> In-Reply-To: <87lho9hlfd.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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Kevin Wolf , Weidong Huang , "qemu-devel@nongnu.org" , stefanha@redhat.com On 2014/10/21 16:33, Markus Armbruster wrote: > Weidong Huang writes: > >> 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? > > I guess failure is fair then. It's close enough to the case where the > guest simply refuses to open the tray. > >>> 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? > > We want QMP "elementary" commands that do just one thing: eject medium > (open tray), remove medium, insert medium, load mediun (close tray). > > I feel "eject medium (open tray)" should work like pressing the button > on a physical drive: if the tray is unlocked, it opens, else the drive > notifies the OS of the button press. The OS should then unlock and open > when possible. > > Likewise, "remove/insert medium" should work just like they do with a > physical drive: the tray needs to be open already. > Cool. Follow the physical behavior completely. Best regards, -Gonglei