From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57881) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvwK5-0001HR-FR for qemu-devel@nongnu.org; Fri, 10 Feb 2012 14:40:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RvwK1-00016j-4N for qemu-devel@nongnu.org; Fri, 10 Feb 2012 14:39:57 -0500 Received: from mail-ee0-f45.google.com ([74.125.83.45]:55691) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvwK0-00016Y-V6 for qemu-devel@nongnu.org; Fri, 10 Feb 2012 14:39:53 -0500 Received: by eekd17 with SMTP id d17so1103871eek.4 for ; Fri, 10 Feb 2012 11:39:52 -0800 (PST) Sender: Paolo Bonzini Message-ID: <4F357284.1070105@redhat.com> Date: Fri, 10 Feb 2012 20:39:48 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1328638189-9534-1-git-send-email-lcapitulino@redhat.com> <4F34CE19.7010806@redhat.com> <20120210150456.7de8af48@doriath.home> <4F355A0A.6050503@redhat.com> In-Reply-To: <4F355A0A.6050503@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 0/5]: QMP: Introduce GUEST_MEDIUM_EJECT & BLOCK_MEDIUM_CHANGED List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org, eblake@redhat.com, Markus Armbruster , Luiz Capitulino On 02/10/2012 06:55 PM, Kevin Wolf wrote: > Am 10.02.2012 18:04, schrieb Luiz Capitulino: >> This reminds me about an earlier try where I did the following, iirc: >> >> 1. added commands blockdev-tray-open, blockdev-tray-close, blockdev-medium-insert, >> blockdev-medium-remove I think this slightly overengineering. eject and change work well enough, we do not need blockdev-medium-insert and blockdev-medium-remove (yet). Of course there can be a new API, just nothing user-visible. >> 2. added the events: BLOCK_TRAY_OPEN, BLOCK_TRAY_CLOSE, BLOCK_MEDIUM_INSERTED >> BLOCK_MEDIUM_REMOVED, which would be emitted when the relating command is issued >> (maybe the events could just be BLOCK_TRAY_CHANGED & BLOCK_MEDIUM_CHANGED) Or even just one event with two boolean arguments. Looks slightly less clean, but it has an advantage: a guest that sends "eject" can wait for an event and will know whether the eject command was really executed (tray = open, medium = none) or just an eject request was obeyed by the guest (tray = open, medium = present). >> Now, maybe the guest eject could also emit BLOCK_TRAY_OPEN & BLOCK_TRAY_CLOSE. Then >> I think this is a complete solution. Yes. > Looks good to me in general. I'm not sure how you're imagining to > implement this, I would prefer not to emit events from the device code, > but only from block.c. ... and yes. :) > Another interesting point is what to do with host CD-ROM passthrough. I > think the TRAY_OPEN/CLOSE part is doable (do Paolo's patches actually do > that, so that we just need to add an event?). It is in the part that I haven't posted yet. > We would have to fake > MEDIUM_REMOVED/INSERTED immediately before a TRAY_CLOSE if the medium > has changed. Not sure about this, the "medium" hasn't changed in the sense that the backend is still the same. With passthrough, eject could become a synonym of tray-open. It is very unintuitive that the device is completely disconnected by the backend. And with passthrough, as soon as the guest ejects my CD I know that I have to remove the medium before the guest reboots. In other words we can expect some kind of collaboration from the user. > LOCK/UNLOCK (which you forgot in your list) is only > initiated by the guest or monitor (eject -f), so there's nothing special > with passthrough. Well, there are a couple of places where we unlock without calling bdrv_lock_medium, those should be fixed so that in the passthrough case we force-unlock the host CD too. Paolo