From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35308) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvWWe-0005uZ-O6 for qemu-devel@nongnu.org; Thu, 09 Feb 2012 11:07:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RvWWX-0008Cz-6w for qemu-devel@nongnu.org; Thu, 09 Feb 2012 11:07:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:62014) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvWWW-0008Cg-U5 for qemu-devel@nongnu.org; Thu, 09 Feb 2012 11:07:05 -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 q19G74Z1029514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 9 Feb 2012 11:07:04 -0500 Date: Thu, 9 Feb 2012 14:07:00 -0200 From: Luiz Capitulino Message-ID: <20120209140700.7c2062a0@doriath.home> In-Reply-To: References: <1328638189-9534-1-git-send-email-lcapitulino@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, eblake@redhat.com, qemu-devel@nongnu.org On Thu, 09 Feb 2012 16:01:21 +0100 Markus Armbruster wrote: > Luiz Capitulino writes: > > > I've tried to implement a BLOCK_MEDIUM_EJECT event that, as we discussed[1], > > would be emitted by guest-initiated ejects and by the QMP/HMP eject and change > > commands. > > > > However, that turned to be a bit problematic, because the eject and change > > commands don't exactly handle tray movements: they actually insert/purge a > > medium from from the drive. > > The monitor commands are complex, because they do several things, and > the exact things they do depends on circumstances. In my experience, > it's best to think in basic operations until you understand the problem, > then bring in the complex commands. If you bring them in any earlier, > you'll get lost in detail and confused. > > > Consider this example: you have a medium inserted and locked; a first eject > > from HMP will tell the guest to eject the medium; if the guest does eject, a > > second eject from HMP will just purge the medium (in which case > > BLOCK_MEDIUM_EJECT is a bad event to be emitted). > > > > What we really want to do is to tell mngt that the medium was purged. > > > > The same is valid for the change command: we want to inform mngt if a medium > > was inserted or purged and not emulate tray movements with two eject events > > as we discussed[1]. > > > > So, the solution I came up with is to have two events: > > > > o GUEST_MEDIUM_EJECTED: emitted when the tray state is changed by the guest > > o BLOCK_MEDIUM_CHANGED: emitted when there's a medium change. This should > > happen when the eject and change QMP/HMP commands are used > > I think what I got in mind is close to your proposal, but the thinking > that gets me there is different. Let me explain it. > > The tray can be modelled as a simple state machine. Our problem "notify > management app of tray-related events" then becomes "notify on state > transition". > > Tray state is just three bits: open/closed, locked/unlocked, > medium/empty. A state transition changes one bit, i.e. we have three > pairs of them. There are a few constraints, all obvious: closed -> open > requires unlocked, and empty <-> medium require open. > > The three pairs of state transitions correspond to three pairs of QMP > events, each with a boolean argument[*]: one for open <-> closed, one for > locked <-> unlocked, and one for medium <-> empty. > > These events report tray state transitions fully by construction. > That's a feature. > > The medium/empty bit belongs to the block layer. So the block layer > should emit the corresponding event. > > The open/closed bit and the locked/unlocked bit belong to the device > model. So the device model should emit the event when it changes the > bit. When device models need to call into the block layer whenever they > change such a bit, then its fine (even desirable) to put the even > emission into the block layer. > > Note there is no mention whatsoever of what caused the state transition. > That's a feature. > > > Now let's compare your proposal to my ideas. Your BLOCK_MEDIUM_CHANGED > appears to track my medium <-> empty. You emit it from the block > layer's bdrv_dev_change_media_cb(). Called to notify device models > whenever the block layer changes media. The "whenever it changes media" > part makes it a convenient choke point. > > 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. The purpose of the note is not to clarify, but to emphasize that the event is about guest initiated ejects. Also, I disagree it's more complex, actually I think it's quite simple vs. emitting the eject event from the eject and change commands, as this can be messy because of their complicated semantics. > This is just my analysis of the problem. If folks think your proposal > serves their needs, and Kevin is happy with it, I won't object. No feedback so far.