From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49496) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsE4V-0006Ke-28 for qemu-devel@nongnu.org; Tue, 31 Jan 2012 08:48:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RsE2d-0000jo-5W for qemu-devel@nongnu.org; Tue, 31 Jan 2012 08:46:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:2632) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsE2c-0000jg-Tg for qemu-devel@nongnu.org; Tue, 31 Jan 2012 08:46:35 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0VDkXth017654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 31 Jan 2012 08:46:33 -0500 Date: Tue, 31 Jan 2012 11:46:30 -0200 From: Luiz Capitulino Message-ID: <20120131114630.2e7f61db@doriath> In-Reply-To: References: <20120124161628.4bf2592c@doriath.home> <4F1F0E9F.8080302@redhat.com> <4F1FC030.2030705@redhat.com> <20120125104204.55eec0a1@doriath.home> <20120126155757.3e97a0c1@doriath.home> <4F2273CF.3050107@redhat.com> <20120130131843.7f88117a@doriath> <4F26BA9A.1050705@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Markus Armbruster Cc: Kevin Wolf , Eric Blake , qemu-devel On Tue, 31 Jan 2012 10:23:59 +0100 Markus Armbruster wrote: > Kevin Wolf writes: > > > Am 30.01.2012 16:18, schrieb Luiz Capitulino: > >> On Fri, 27 Jan 2012 10:52:15 +0100 > >> Kevin Wolf wrote: > >> > >>> Am 26.01.2012 18:57, schrieb Luiz Capitulino: > >>>> On Wed, 25 Jan 2012 10:42:04 -0200 > >>>> Luiz Capitulino wrote: > >>>> > >>>>> On Wed, 25 Jan 2012 09:41:20 +0100 > >>>>> Kevin Wolf wrote: > >>>>> > >>>>>> Am 24.01.2012 21:03, schrieb Eric Blake: > >>>>>>> On 01/24/2012 11:16 AM, Luiz Capitulino wrote: > >>>>>>>> Libvirt wants to be notified when the guest ejects a medium, so that > >>>>>>>> it can update its view of the guest. > >>>>>>>> > >>>>>>>> This code has been originally written by Daniel Berrange. It adds > >>>>>>>> the event to IDE and SCSI emulation. > >>>>>>>> > >>>>>>>> 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. > >>>>> The exception is if it allows HMP to run in parallel with QMP, but I don't think > >>>>> this is recommended (at least not for commands that change any VM state). > >>>> > >>>> Let me elaborate more. We have two options: > >>>> > >>>> 1. Emit the event for guest initiated ejects (this patch, although I think > >>>> the event should be renamed to GUEST_MEDIUM_EJECT) > >>>> > >>>> 2. Emit the event for guest & QMP initiated ejects, that's, also emit the > >>>> event for the eject and change commands > >>>> > >>>> The first thing to note is that, they're not mutually exclusive. If we do > >>>> item 1 now, we can add 2 later (as a different event). > >>>> > >>>> But my point is that doing 2 is problematic and we should avoid it. The problem > >>>> is that the semantics of eject and change are complex and/or buggy. And something > >>>> I've learned about confusing semantics in QMP is that, they will give you headaches > >>>> soon or later. > >>> > >>> But I'm not really interested in the semantics of QMP commands, because > >>> they are irrelevant for the events. > >> > >> I do think they are relevant, because the event will have to match what > >> the eject/change commands do with the tray. If what they do is messy, the > >> event will turn out to be messy too. > >> > >> Now, I don't doubt this can be all fixed and made clean. I'm just not sure > >> if it's worth it. > > > > If a mess best describes to the outside what we're doing to the device, > > then having a messy event is the best you can expect. Or in other words, > > if you're doing messy things with the device and you straighten things > > out in the event generation, then your events are lying to the > > management tools. > > Yup. The event is merely a passive sensor. If reality is messy, sensor > data better reflect that. > > Maybe it's easier to understand from a distance, so let's examine a more > distant example: filesystem event monitoring with inotify(), > specifically file permissions change. The event is simple enough: you > get it when file permissions change. Now imagine chmod(2) was > "improved" to refuse to set write bits unless read bits are also set, > but only on Tuedays. That's a messy chmod() indeed. But the event > remains as simple and clean as ever: you still get it when file > permissions change. > > Back to QMP. In my opinion, the simple and clean event is "tray moved". > Emit it when the tray moves, regardless of what made it move. I'll give it a tray. Oh, I meant a try :) > > Yes, the management app gets the event even when it itself directly > triggered the move by commanding a media eject. That's a feature. It > also gets the event when its media eject command actually becomes a > polite request to the guest OS, because the tray happens to be locked, > and the guest OS complies. That's a feature, too. > > [...] >