From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MKFLO-0002A9-W5 for qemu-devel@nongnu.org; Fri, 26 Jun 2009 13:36:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MKFLJ-00029J-En for qemu-devel@nongnu.org; Fri, 26 Jun 2009 13:36:09 -0400 Received: from [199.232.76.173] (port=37570 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MKFLJ-00029G-9G for qemu-devel@nongnu.org; Fri, 26 Jun 2009 13:36:05 -0400 Received: from mx20.gnu.org ([199.232.41.8]:1629) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MKFLI-0004VZ-QB for qemu-devel@nongnu.org; Fri, 26 Jun 2009 13:36:05 -0400 Received: from mail-ew0-f211.google.com ([209.85.219.211]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MKFLG-0002Sy-UD for qemu-devel@nongnu.org; Fri, 26 Jun 2009 13:36:03 -0400 Received: by ewy7 with SMTP id 7so3213414ewy.34 for ; Fri, 26 Jun 2009 10:36:00 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4A44E2F3.8050804@codemonkey.ws> References: <4A412339.5000109@redhat.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> <4A44CB74.1070808@codemonkey.ws> <4A44E2F3.8050804@codemonkey.ws> Date: Fri, 26 Jun 2009 19:36:00 +0200 Message-ID: <5b31733c0906261036o272bcd8xffc0f2e209b778a5@mail.gmail.com> Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file From: Filip Navara Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "ehabkost@redhat.com" , Stefano Stabellini , "jan.kiszka@siemens.com" , "dlaor@redhat.com" , "qemu-devel@nongnu.org" , Luiz Capitulino , Avi Kivity , Vincent Hanquez On Fri, Jun 26, 2009 at 5:02 PM, Anthony Liguori wro= te: > Anthony Liguori wrote: >> >> Avi Kivity wrote: >>> >>> Merging is a meaningless milestone since the protocol will not be >>> enabled. =A0Since we'll miss 0.11 in reality we have 7-8 months before = the >>> protocol can be used in production. =A0IMO you're optimizing for the sh= ort >>> term, disregarding long-term maintenance, and disregarding ease of >>> implementation for users of the qemu monitor. >> > Here's an updated grammar. > > One benefit of using our own grammar over just JSON-RPC that is line base= d > is that lines form discrete PDUs. =A0If you wanted to implement a JSON-RP= C > parser, you would have to be able to either invent your own PDU transmiss= ion > mechanism or rely on the JSON parser to determine message boundaries. =A0= Since > the later is likely to be a recursive decent parser, this is difficult to > work into an asynchronous client library. =A0The same is true for XML-RPC= . > With XML-RPC, you rely on HTTP's Content-Length header to determine > boundaries. > > By having a well defined PDU, you can hand lines to the parser and be sur= e > that the recursion will complete without requiring more data. > > Regards, > > Anthony Liguori > > # QMP 1.0 > > # v1 -> v2 > # =A0o allow integer in symbol names (C-style) > # =A0o allow negative integer/floats > # =A0o no newlines in strings > # =A0o one value per response_data line > > __skip__: [ \t]+ > > symbol: [A-Za-z_\-][A-Za-z_\-0-9]* > > decimalinteger: (-)?[1-9][0-9]+ > hexinteger: 0x[0-9]+ > float: (-)?[0-9]+\.[0-9]+ > > string: \"([^\"\\\n]|(\\[0-9][0-9][0-9]))*\" | symbol > > number: float | decimalinteger | hexinteger > > comma_arg_list: value (',' comma_arg_list)? > list: '[' comma_arg_list? ']' > > dict_list: string ':' value (',' dict_list)? > dictionary: '{' dict_list? '}' > > value: (string | number | list | dictionary) > > arg_list: value arg_list? > > command: symbol arg_list? '\n' > > response_status: ('+' | '-') number string? '\n' > response_data: '=3D' value '\n' > async_msg: '*' arg_list '\n' > > response: async_msg | response_data* response_status > > Thanks for writing this down, I really appreciate it. It answers some of the issues I had with the original protocol proposal (interruption of multi-line responses by asynchronous events). What bothers me though is that it's not LL(1) grammar (not a big problem, but writing LL parsers by hand is much easier) and not all floats can be represented (eg. NaN). String is underdefined - does the syntax represent bytes or characters? If characters then the \nnn syntax is insufficient. There's no syntax for binary data which may eventually be required (FDT machine description), but that can be relatively easily added with something like blob :=3D 'B' base64-string base64-string :=3D \" ([A-Za-z0-9+/]*) \" and adjusting "value". Note that IMAP uses special literal symbols to send binary data and the data transfer must be negotiated (unless LITERAL+ extension is used). It looks like this S: ... RFC822.BODY {} C: + Ok, send the data S: It makes the protocol much harder to implement and almost nobody does it right (including major servers), so I would recommend against anything like that. In the ideal case QEMU will never need large enough blobs to warrant it. I'm still not convinced that reinventing a text-based protocol is way to go, but I welcome the effort for formal specification of what you had in mind. Best regards, Filip Navara