From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39296) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvtuH-0001nC-Sk for qemu-devel@nongnu.org; Fri, 10 Feb 2012 12:05:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RvtuC-0001r7-2N for qemu-devel@nongnu.org; Fri, 10 Feb 2012 12:05:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50171) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvtuB-0001q0-Oe for qemu-devel@nongnu.org; Fri, 10 Feb 2012 12:05:03 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1AH50Rg013896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 10 Feb 2012 12:05:01 -0500 Date: Fri, 10 Feb 2012 15:04:56 -0200 From: Luiz Capitulino Message-ID: <20120210150456.7de8af48@doriath.home> In-Reply-To: References: <1328638189-9534-1-git-send-email-lcapitulino@redhat.com> <4F34CE19.7010806@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Markus Armbruster Cc: kwolf@redhat.com, Paolo Bonzini , eblake@redhat.com, qemu-devel@nongnu.org On Fri, 10 Feb 2012 10:36:06 +0100 Markus Armbruster wrote: > Paolo Bonzini writes: > > > On 02/09/2012 04:01 PM, Markus Armbruster wrote: > >> Your GUEST_MEDIUM_EJECTED does*not* track my open<-> closed. I think > >> it's more complex than a straight open<-> closed event. Evidence: your > >> event documentation in qmp-events.txt needs an extra note to clarify > >> when exactly the event is emitted. > > > > I think I agree at this point that always generating an event for open > > <-> closed would make sense. > > > > However, we need to write a proper state machine rather than keeping > > it implicit. Events would be generated in the state machine rather > > than magically in bdrv_eject/bdrv_close. We could also take the > > occasion to move all this out of block.c which is becoming huge. So > > we would have: > > > > guest eject, tray locked: > > nothing > > > > guest eject, tray unlocked: > > BLOCK_MEDIUM_EJECT > > empty/full not affected > > > > guest eject, tray open: > > BLOCK_MEDIUM_EJECT > > empty/full not affected I think we should only emit the event when the tray actually moves, that's what mngt is interested in. > > eject, tray locked: > > eject request sent to guest > > guest responds to eject request as above > > > > eject, tray unlocked and full: > > BLOCK_MEDIUM_EJECT > > BLOCK_MEDIUM_CHANGED I don't think BLOCK_MEDIUM_EJECT should be emitted if the tray is already open. > > eject, tray unlocked and empty: > > BLOCK_MEDIUM_EJECT And closed... > > eject, tray open and full: > > BLOCK_MEDIUM_CHANGED > > > > eject, tray open and empty: > > no event Yes. > > > > change, tray locked: > > eject request sent to guest > > guest responds to eject request as above > > > > change, tray unlocked and full: > > BLOCK_MEDIUM_EJECT (to open) > > BLOCK_MEDIUM_CHANGED (perhaps twice? full -> empty -> full) > > BLOCK_MEDIUM_EJECT (to close) > > > > change, tray unlocked and empty: > > BLOCK_MEDIUM_EJECT (to open) > > BLOCK_MEDIUM_CHANGED > > BLOCK_MEDIUM_EJECT (to close) > > > > change, tray open and full: > > BLOCK_MEDIUM_CHANGED (perhaps twice?) > > BLOCK_MEDIUM_EJECT (to close) > > > > change, tray open and empty: > > BLOCK_MEDIUM_CHANGED > > BLOCK_MEDIUM_EJECT (to close) > > > > Luiz, can you try making a proof of concept of this state machine? > > > > Events then would hopefully come natural. > > Making the tray state machine explicit may make sense. But we also need > to preserve the sane guest / host split: tray movement and locking is > guest matter, handling media in an open tray is host matter. > > Moreover, let's not think "eject" and "change". These are complex > actions that should be built from basic parts. The verbs I want used > are open, close, lock, unlock, insert, remove. > > Eject becomes something like open (if not already open) + remove (if > open and not empty). > > Change becomes something like open (if not already open) + remove (if > open and not empty) + insert (if empty) + close (if open). 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 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) 3. re-wrote eject and change in terms of the new commands, note that you get the events for free Now, maybe the guest eject could also emit BLOCK_TRAY_OPEN & BLOCK_TRAY_CLOSE. Then I think this is a complete solution. Do you guys agree?