From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nea84-00071F-WE for qemu-devel@nongnu.org; Mon, 08 Feb 2010 15:22:45 -0500 Received: from [199.232.76.173] (port=56783 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nea84-00070v-Fd for qemu-devel@nongnu.org; Mon, 08 Feb 2010 15:22:44 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nea82-0008H9-C8 for qemu-devel@nongnu.org; Mon, 08 Feb 2010 15:22:44 -0500 Received: from mail-fx0-f222.google.com ([209.85.220.222]:37643) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nea81-0008GD-9P for qemu-devel@nongnu.org; Mon, 08 Feb 2010 15:22:41 -0500 Received: by fxm22 with SMTP id 22so236066fxm.16 for ; Mon, 08 Feb 2010 12:22:40 -0800 (PST) Message-ID: <4B70728A.4000600@codemonkey.ws> Date: Mon, 08 Feb 2010 14:22:34 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Two QMP events issues References: <20100208114145.4bd64349@doriath> <20100208141218.GG17328@redhat.com> <4B702470.5080401@codemonkey.ws> <20100208145653.GA25256@redhat.com> <4B702A21.1070808@codemonkey.ws> <20100208162521.788f9c02@doriath> <4B706290.7020104@codemonkey.ws> <20100208175943.3ed2bf88@doriath> In-Reply-To: <20100208175943.3ed2bf88@doriath> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: qemu-devel@nongnu.org, armbru@redhat.com On 02/08/2010 01:59 PM, Luiz Capitulino wrote: > > Looks reasonable to me, what do think Daniel? > > Note that if we agree on the 'context design', I'll have to change > VNC's events names.. > Let me give you a few suggestions before diving into it. context might not be the best name. For event generated by devices, the event should be raised with something like qdev_event(&s->dev, QMPEV_WD_EXPIRED, ...). The context argument should allow a client to determine which device raised the event. So it could be a combination of the device's qdev name and it's id. For event generated by non-qdev mechanisms, we should try our best to associate context with that event. For instance, a DISCONNECT event happens to a particular session. We don't quite have VNC session ids yet but if we did, it would make sense to include that in the context info. So my thinking is that we don't just want context to serve as a classification mechanism, but we want it to indicate what subsystem/device/session generated the event. Regards, Anthony Liguori