From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZ4VK-0007Y4-Fq for qemu-devel@nongnu.org; Sun, 24 Jan 2010 10:35:58 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZ4VG-0007WN-M8 for qemu-devel@nongnu.org; Sun, 24 Jan 2010 10:35:58 -0500 Received: from [199.232.76.173] (port=33803 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZ4VG-0007WJ-Ib for qemu-devel@nongnu.org; Sun, 24 Jan 2010 10:35:54 -0500 Received: from mail-yx0-f188.google.com ([209.85.210.188]:62467) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NZ4VG-0007XE-II for qemu-devel@nongnu.org; Sun, 24 Jan 2010 10:35:54 -0500 Received: by yxe26 with SMTP id 26so2266024yxe.4 for ; Sun, 24 Jan 2010 07:35:53 -0800 (PST) Message-ID: <4B5C68D6.6090502@codemonkey.ws> Date: Sun, 24 Jan 2010 09:35:50 -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> <20100124110725.GA5668@shareable.org> In-Reply-To: <20100124110725.GA5668@shareable.org> 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: Jamie Lokier Cc: qemu-devel@nongnu.org, Luiz Capitulino , Avi Kivity , armbru@redhat.com On 01/24/2010 05:07 AM, Jamie Lokier wrote: > 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. >> > I'd like to be able to connect and be sure not to receive any async > messages, from simple scripts with simple output parsing. > You can't have simple output parsing with QMP. You need a full JSON stack. The simplest script would be a python script that uses the builtin json support. Having async messages means that you'll have to loop on recv in order make sure that the response is a command response vs. an async message. It's just a few lines more of code so I have a hard time believing it's really a problem. But what you probably want is a python QMP library and that would mean you wouldn't need the few more lines of code. > If async messages can only be received as a result of commands which > trigger individual messages, that will be achieved. > > But it would be a nice little bonus if disabling async messages caused > all slow commands to be synchronous - that is, the async result > message becomes the command's synchronous result. > I know what you're getting at but I think it's the wrong target for QMP. The goal is not to allow simple, hacky clients, but to provide a robust management API. It should not be difficult to use, but parsing it in a shell with awk is not a requirement in my mind :-) Regards, Anthony Liguori