From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55637) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0yFm-0008Fi-EY for qemu-devel@nongnu.org; Fri, 24 Feb 2012 11:44:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S0yFl-0000DH-5A for qemu-devel@nongnu.org; Fri, 24 Feb 2012 11:44:18 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:55555) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0yFk-0000D5-Vb for qemu-devel@nongnu.org; Fri, 24 Feb 2012 11:44:17 -0500 Received: by pbbro12 with SMTP id ro12so3355690pbb.4 for ; Fri, 24 Feb 2012 08:44:15 -0800 (PST) Message-ID: <4F47BE5B.6010602@codemonkey.ws> Date: Fri, 24 Feb 2012 10:44:11 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1329506504-29152-1-git-send-email-lcapitulino@redhat.com> <1329506504-29152-6-git-send-email-lcapitulino@redhat.com> <4F44EC3B.9090902@redhat.com> <20120223101717.5e5886b9@doriath.home> <4F47B43C.8050008@codemonkey.ws> <20120224143911.018b2073@doriath.home> In-Reply-To: <20120224143911.018b2073@doriath.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 5/5] qmp: add DEVICE_TRAY_MOVED event List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Kevin Wolf , pbonzini@redhat.com, eblake@redhat.com, Markus Armbruster , qemu-devel@nongnu.org On 02/24/2012 10:39 AM, Luiz Capitulino wrote: > On Fri, 24 Feb 2012 10:01:00 -0600 > Anthony Liguori wrote: > >> On 02/23/2012 08:08 AM, Markus Armbruster wrote: >>> Luiz Capitulino writes: >>> >>>> On Thu, 23 Feb 2012 08:50:08 +0100 >>>> Markus Armbruster wrote: >>>> >>>>> Kevin Wolf writes: >>>>> >>>>>> Am 17.02.2012 20:21, schrieb Luiz Capitulino: >>>>>>> It's emitted whenever the tray is moved by the guest or by HMP/QMP >>>>>>> commands. >>>>>>> >>>>>>> Signed-off-by: Luiz Capitulino >>>>>>> --- >>>>>>> QMP/qmp-events.txt | 18 ++++++++++++++++++ >>>>>>> block.c | 24 ++++++++++++++++++++++++ >>>>>>> monitor.c | 3 +++ >>>>>>> monitor.h | 1 + >>>>>>> 4 files changed, 46 insertions(+), 0 deletions(-) >>>>>>> >>>>>>> diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt >>>>>>> index 06cb404..9286af5 100644 >>>>>>> --- a/QMP/qmp-events.txt >>>>>>> +++ b/QMP/qmp-events.txt >>>>>>> @@ -26,6 +26,24 @@ Example: >>>>>>> Note: If action is "stop", a STOP event will eventually follow the >>>>>>> BLOCK_IO_ERROR event. >>>>>>> >>>>>>> +DEVICE_TRAY_MOVED >>>>>>> +----------------- >>>>>>> + >>>>>>> +It's emitted whenever the tray of a removable device is moved by the guest >>>>>>> +or by HMP/QMP commands. >>>>>>> + >>>>>>> +Data: >>>>>>> + >>>>>>> +- "device": device name (json-string) >>>>>> >>>>>> For me, a device name is something related to qdev. 'device' is a >>>>>> misnomer consistently used in all QMP commands so far and we can't fix >>>>>> it any more, but at least the documentation should clarify what is meant >>>>>> (that's for a follow-up patch). >>>>> >>>>> We can fix it if we really want to: rename, then add the old name as >>>>> alias for backward compatibility. Pick your favourite flavor of cruft. >>>> >>>> I like it, new events won't have the cruft. >>> >>> If we reserve "device" for device models, we need sensible names for >>> device backends. One each for block, net and char. There's some >>> precedence for "blockdev", "netdev", "chardev", but they contain "dev", >>> so there's still some overloading of the name "device". Better ideas? >> >> For 1.2 (when QOM is considered stable), this should become pathname. Given a >> path, a client can determine what the type of the object is (by reading the type >> property). >> >> In fact, I'd like to see all events have a pathname of origin. This would >> probably become part of the QMP protocol itself. >> >> This gives us a mechanism to subscribe to events from specific objects. > > This is 1.2 material, right? Yes. > I'm asking because the conversion of events to the qapi is not too far away, > but I think that using QOM will somewhat deprecate the code you have in the > glib branch (besides having to wait for 1.2)? I have some vague ideas about what to do here. One thought would be to have a standard notifier mechanism in Object that was advertised as a property type. We could then provide an interface via QMP to [un]subscribe to a notifier property. I won't get to this until the 1.2 time frame though. My goals for 1.1 are to get qbus conversions merged and refactor IRQs/MemoryRegions to use QOM. If time permits, also refactor the PC to better use QOM. If someone wants to tackle events in QOM, I'd be happy to provide some suggestions on where to start. Regards, Anthony Liguori Regards, Anthony Liguori