From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRJ5I-0007BO-RL for qemu-devel@nongnu.org; Tue, 31 May 2011 03:09:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QRJ5H-0000fl-VL for qemu-devel@nongnu.org; Tue, 31 May 2011 03:09:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62256) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRJ5H-0000fa-KG for qemu-devel@nongnu.org; Tue, 31 May 2011 03:09:47 -0400 Date: Tue, 31 May 2011 12:39:42 +0530 From: Amit Shah Message-ID: <20110531070942.GA27934@amit-x200.redhat.com> References: <1306524712-13050-1-git-send-email-lcapitulino@redhat.com> <1306524712-13050-3-git-send-email-lcapitulino@redhat.com> <4DE3594F.20406@redhat.com> <20110530112123.39ca4dc6@doriath> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH 2/3] QMP: Add BLOCK_MEDIA_EJECT event documentation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Kevin Wolf , aliguori@us.ibm.com, qemu-devel@nongnu.org, Luiz Capitulino On (Mon) 30 May 2011 [16:54:22], Markus Armbruster wrote: > Luiz Capitulino writes: ... > >> The monitor command 'eject' already caused a lot of confusion, please > >> don't make the same mistake in this event name. Even though I know more > >> or less what eject can mean in qemu, I'm not sure what "eject" means for > >> you in the context of this event. > > > > I'll change it to report the tray status instead, as suggested by Markus. > > > >> The 'eject' monitor command means that the image is closed and the > >> BlockDriverState doesn't point to any image file any more. And then > >> there's bdrv_eject(), which is what the guest can do, and it's about the > >> virtual tray status. > >> > >> Having a single event for both doesn't make sense because they are > >> fundamentally different. Something like BLOCKDEV_CLOSE would be the > >> right name for the 'eject' monitor command and maybe something like > >> BLOCKDEV_TRAY_STATUS for the other one. > > > > Well, there are two problems here. First, we shouldn't report something > > like BLOCKDEV_CLOSE because closing a BlockDriverState is something > > internal to qemu that clients/users shouldn't know about. The second > > problem is that, unfortunately, clients do use "eject" to eject a > > removable media. Actually it's _the_ interface available for that, so > > not emitting the event there will probably confuse clients as much as > > not having the event at all. > > > > Maybe, a better solution is to fix eject to really eject the media > > instead of closing its BlockDriverState and drop the event from the change > > command. > > Monitor command "eject" conflates three actions: open tray, remove media > (if any), close tray. > > Monitor command "change" conflates four actions: open tray, remove media > (if any), insert media, close tray. > > Except they don't really move the tray in a guest-visible manner. They > teleport the media. I figure that should be changed. Agreed. We should be able to report these events to clients as well as guests. Amit