From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MKBNa-0007We-0A for qemu-devel@nongnu.org; Fri, 26 Jun 2009 09:22:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MKBNU-0007S4-Al for qemu-devel@nongnu.org; Fri, 26 Jun 2009 09:22:08 -0400 Received: from [199.232.76.173] (port=54001 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MKBNU-0007Ru-8A for qemu-devel@nongnu.org; Fri, 26 Jun 2009 09:22:04 -0400 Received: from mail-ew0-f211.google.com ([209.85.219.211]:64168) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MKBNT-0007uX-SN for qemu-devel@nongnu.org; Fri, 26 Jun 2009 09:22:04 -0400 Received: by ewy7 with SMTP id 7so2982337ewy.34 for ; Fri, 26 Jun 2009 06:22:03 -0700 (PDT) Message-ID: <4A44CB74.1070808@codemonkey.ws> Date: Fri, 26 Jun 2009 08:21:56 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file References: <4A412339.5000109@redhat.com> <4A412659.1080803@us.ibm.com> <20090623220204.GA5612@snarc.org> <4A415C30.7030301@us.ibm.com> <20090624010108.GA6537@snarc.org> <4A42200C.6060600@codemonkey.ws> <5b31733c0906240857g546316e0pd92fee9afe6115fa@mail.gmail.com> <4A4252DD.70300@redhat.com> <20090624190539.GR14121@shareable.org> <5b31733c0906241224j50baa7e6lc80b8c79c5d6baa7@mail.gmail.com> <20090624211358.GA14121@shareable.org> <4A43768A.2090604@eu.citrix.com> <4A438FDD.5060206@redhat.com> <4A43935D.6000506@codemonkey.ws> <4A4395B8.4010401@redhat.com> <4A43BD5D.80307@codemonkey.ws> <4A43C264.6060803@redhat.com> <4A43D600.8060605@codemonkey.ws> <4A449113.8070907@redhat.com> In-Reply-To: <4A449113.8070907@redhat.com> Content-Type: text/plain; charset=UTF-8; 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: "ehabkost@redhat.com" , Stefano Stabellini , "jan.kiszka@siemens.com" , "dlaor@redhat.com" , "qemu-devel@nongnu.org" , Luiz Capitulino , Filip Navara , Vincent Hanquez Avi Kivity wrote: > Merging is a meaningless milestone since the protocol will not be > enabled. Since we'll miss 0.11 in reality we have 7-8 months before > the protocol can be used in production. IMO you're optimizing for the > short term, disregarding long-term maintenance, and disregarding ease > of implementation for users of the qemu monitor. QMP is: __skip__: [ \t]+ symbol: [A-Za-z_\-]+ decimalinteger: [1-9][0-9]+ hexinteger: 0x[0-9]+ float: [0-9]+\.[0-9]+ string: \"([^\"\\]|(\\[0-9][0-9][0-9]))*\" | symbol number: float | decimalinteger | hexinteger value: string | number arg_list: value arg_list? command: symbol arg_list? '\n' response_status: ('+' | '-') number arg_list? '\n' response_data: '=' arg_list '\n' async_msg: '*' arg_list '\n' response: async_msg | response_data* response_status Client sends 'command's, server responses with 'response'. Responses of response type '*' are server initiated messages. Otherwise, a server always responses to a command with a response type of '+' or '-'. A client sits in a 'response' parsing loop. Each sent 'command' is queued in a FIFO and responses are associated with the commands based on the FIFO order. 'async_msg's do not have associated commands. All strings are UTF-8. Human readable messages depend on the locale used by QEMU. N.B. there are some subtle changes to Luiz's original proposal to make QMP more well-formed. In particular, more things have to be encoded as strings than previously. This is a very well formed RPC now. It can be trivially implemented in something like Python. We can add higher level types. For instance, we could: -value: string | number +value: (string | number | list | dictionary) +comma_arg_list: value (',' comma_arg_list)? +list: '[' comma_arg_list? ']' + +dict_list: string ':' value (',' dict_list)? +dictionary: '{' dict_list? '}' And then we basically have JSON. The changes on top of Luiz's current patchset would be introducing an error code and adding more structure to monitor_printf() which I asked for anyway. Regards, Anthony Liguori