From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54009) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rq2xW-0008Ud-Gb for qemu-devel@nongnu.org; Wed, 25 Jan 2012 08:32:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rq2xU-0007jO-8c for qemu-devel@nongnu.org; Wed, 25 Jan 2012 08:32:18 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:39954) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rq2xT-0007ix-MQ for qemu-devel@nongnu.org; Wed, 25 Jan 2012 08:32:16 -0500 Received: by pbdd2 with SMTP id d2so4260258pbd.4 for ; Wed, 25 Jan 2012 05:32:14 -0800 (PST) Sender: Paolo Bonzini Message-ID: <4F200456.5010507@redhat.com> Date: Wed, 25 Jan 2012 14:32:06 +0100 From: Paolo Bonzini 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> In-Reply-To: <4F20026B.4020801@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: qemu-devel , Eric Blake , Kevin Wolf , Luiz Capitulino , Markus Armbruster 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. 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. Paolo