From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZ34a-0000ZA-Pb for qemu-devel@nongnu.org; Sun, 24 Jan 2010 09:04:16 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZ34V-0000WZ-Pm for qemu-devel@nongnu.org; Sun, 24 Jan 2010 09:04:16 -0500 Received: from [199.232.76.173] (port=57311 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZ34V-0000WE-41 for qemu-devel@nongnu.org; Sun, 24 Jan 2010 09:04:11 -0500 Received: from mail-gx0-f223.google.com ([209.85.217.223]:33257) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NZ34U-0006f2-Pj for qemu-devel@nongnu.org; Sun, 24 Jan 2010 09:04:10 -0500 Received: by gxk23 with SMTP id 23so2859495gxk.2 for ; Sun, 24 Jan 2010 06:04:10 -0800 (PST) Message-ID: <4B5C5358.2000900@codemonkey.ws> Date: Sun, 24 Jan 2010 08:04:08 -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> <4B59E8DF.5020001@codemonkey.ws> <4B5C2251.7050509@redhat.com> In-Reply-To: <4B5C2251.7050509@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: Avi Kivity Cc: armbru@redhat.com, aliguori@us.ibm.com, qemu-devel@nongnu.org, Luiz Capitulino On 01/24/2010 04:34 AM, Avi Kivity wrote: > 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. To be honest, I don't think there's really a need to mask individual messages. A client can always ignore messages it doesn't care about. There is no side effect of receiving a message so there is no functional implication of receiving messages you don't care about. The only time it would matter is if we had a really high volume of messages. I'd suggest waiting until a message is introduced that could potentially have a high rate and then implement a mechanism to mask it. For now, it just adds unnecessary complexity. Regards, Anthony Liguori