From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rq35J-0004CJ-6D for qemu-devel@nongnu.org; Wed, 25 Jan 2012 08:40:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rq35C-0000ui-Td for qemu-devel@nongnu.org; Wed, 25 Jan 2012 08:40:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55832) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rq35C-0000uS-Ji for qemu-devel@nongnu.org; Wed, 25 Jan 2012 08:40:14 -0500 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0PDeDmY018507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 25 Jan 2012 08:40:13 -0500 Message-ID: <4F200709.7000701@redhat.com> Date: Wed, 25 Jan 2012 14:43:37 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <20120124161628.4bf2592c@doriath.home> <4F1F0E9F.8080302@redhat.com> <4F1FC030.2030705@redhat.com> <20120125104204.55eec0a1@doriath.home> <4F20026B.4020801@redhat.com> <4F200456.5010507@redhat.com> In-Reply-To: <4F200456.5010507@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] qmp: add BLOCK_MEDIUM_EJECT event List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Markus Armbruster , Eric Blake , qemu-devel , Luiz Capitulino Am 25.01.2012 14:32, schrieb Paolo Bonzini: > On 01/25/2012 02:23 PM, Kevin Wolf wrote: >>>>> Please, note that this only covers guest initiated ejects, that's, >>>>> the QMP/HMP commands 'eject' and 'change' are not covered. >>>> >>>> What's the reason for this behaviour? It feels inconsistent. >>> >>> I don't think it's inconsistent because we're limiting it to guest initiated >>> actions. Also, the mngt app knows when it sends a 'eject' or 'change' command. >> >> Yes, management shouldn't need an event in order to see what it just did >> itself. I haven't really looked at the code yet, but what I want to >> avoid is that we have to pass a flag all the way through qemu just so we >> don't send an event in the end. This might not be the case today, but >> after some more cleanup of the code it might just turn out like this. > > Management must be ready anyway to receive an event in response to > eject/change actions that it started, because the guest might be > trapping the host's eject requests ("press the button") and turning them > into guest-initiated ejects. This is what recent udev does. Good point. The QMP client would still get an error that the device is locked, and only later receive the event that the guest ejected the medium, right? > Thus, a reliable eject procedure must be as follows: > > 1) Eject the disc > > 2) query the state of the tray. If it is open, poll for eject events > and consume them. If it is closed, either exit or wait for an eject > event to arrive. > > We can document that the event MAY NOT be reported for host-initiated > ejects. It is future-proof and actually closer to what happens in > practice if you consider a wide range of guests. In which case we did have an eject request, but we didn't actually eject. So I think defining it as being emitted whenever something is ejected/the tray is opened makes sense. Kevin