From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49519) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvxNj-0007qu-45 for qemu-devel@nongnu.org; Fri, 10 Feb 2012 15:47:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RvxNi-0002sl-7M for qemu-devel@nongnu.org; Fri, 10 Feb 2012 15:47:47 -0500 Received: from mail-ee0-f45.google.com ([74.125.83.45]:45241) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvxNi-0002sZ-2n for qemu-devel@nongnu.org; Fri, 10 Feb 2012 15:47:46 -0500 Received: by eekd17 with SMTP id d17so1121120eek.4 for ; Fri, 10 Feb 2012 12:47:45 -0800 (PST) Sender: Paolo Bonzini Message-ID: <4F35826D.6080408@redhat.com> Date: Fri, 10 Feb 2012 21:47:41 +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> <4F357284.1070105@redhat.com> In-Reply-To: <4F357284.1070105@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: , Cc: Kevin Wolf , Luiz Capitulino , eblake@redhat.com, qemu-devel@nongnu.org, Markus Armbruster On 02/10/2012 08:39 PM, Paolo Bonzini wrote: >>> >>> 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. Hmm... I don't know... The more I think about it, the more I like Luiz's original proposal of only signaling guest-initiated ejects. I won't hold up any other patch that works, but I cannot think of something that is as easily usable by management in a non-racy way. Paolo