From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NYNsu-0006t3-3d for qemu-devel@nongnu.org; Fri, 22 Jan 2010 13:05:28 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NYNsp-0006sJ-7s for qemu-devel@nongnu.org; Fri, 22 Jan 2010 13:05:27 -0500 Received: from [199.232.76.173] (port=51965 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NYNsp-0006sG-1u for qemu-devel@nongnu.org; Fri, 22 Jan 2010 13:05:23 -0500 Received: from mail-qy0-f194.google.com ([209.85.221.194]:64581) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NYNso-0002pw-Is for qemu-devel@nongnu.org; Fri, 22 Jan 2010 13:05:22 -0500 Received: by qyk32 with SMTP id 32so776503qyk.4 for ; Fri, 22 Jan 2010 10:05:22 -0800 (PST) Message-ID: <4B59E8DF.5020001@codemonkey.ws> Date: Fri, 22 Jan 2010 12:05:19 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 08/11] QMP: Asynchronous messages enable/disable support References: <1264108180-3666-1-git-send-email-lcapitulino@redhat.com> <1264108180-3666-9-git-send-email-lcapitulino@redhat.com> In-Reply-To: <1264108180-3666-9-git-send-email-lcapitulino@redhat.com> 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: aliguori@us.ibm.com, avi@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com On 01/21/2010 03:09 PM, Luiz Capitulino wrote: > This commit disables asynchronous messages by default and > introduces two new QMP commands: async_msg_enable and > async_msg_disable. > > Each QMP Monitor has its own set of asynchronous messages, > so for example, if QEMU is run with two QMP Monitors async > messages setup in one of them doesn't affect the other. > > To implement this design a bitmap is introduced to the > Monitor struct, each async message is represented by one bit. > > Signed-off-by: Luiz Capitulino > Ah, I see I was a little confused. I'd suggest making async message masking an independent mechanism. Capabilities should strictly deal with protocol changes, not feature details. For instance, protocol timestamps are something would reasonable considered a capability. Extended data types would be a capability. Another way to look at it, is that if you're writing a client library, the capability negotiation should be entirely invisible to the end API user. Regards, Anthony Liguori