From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NYzoC-0006Ux-Me for qemu-devel@nongnu.org; Sun, 24 Jan 2010 05:35:08 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NYzo7-0006SV-8W for qemu-devel@nongnu.org; Sun, 24 Jan 2010 05:35:07 -0500 Received: from [199.232.76.173] (port=33300 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NYzo6-0006SM-Pq for qemu-devel@nongnu.org; Sun, 24 Jan 2010 05:35:02 -0500 Received: from mx1.redhat.com ([209.132.183.28]:31101) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NYzo6-0007TH-Bi for qemu-devel@nongnu.org; Sun, 24 Jan 2010 05:35:02 -0500 Message-ID: <4B5C2251.7050509@redhat.com> Date: Sun, 24 Jan 2010 12:34:57 +0200 From: Avi Kivity 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> <4B59E8DF.5020001@codemonkey.ws> In-Reply-To: <4B59E8DF.5020001@codemonkey.ws> 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: Anthony Liguori Cc: armbru@redhat.com, aliguori@us.ibm.com, qemu-devel@nongnu.org, Luiz Capitulino On 01/22/2010 08:05 PM, Anthony Liguori wrote: > 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. > I agree with that, but we can look at async messages as a baseline protocol capability (thus no negotiation required), and the new command only enabled individual messages. -- error compiling committee.c: too many arguments to function