From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MKy6H-0006ng-Cw for qemu-devel@nongnu.org; Sun, 28 Jun 2009 13:23:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MKy6C-0006iD-LQ for qemu-devel@nongnu.org; Sun, 28 Jun 2009 13:23:33 -0400 Received: from [199.232.76.173] (port=42620 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MKy6C-0006i8-IG for qemu-devel@nongnu.org; Sun, 28 Jun 2009 13:23:28 -0400 Received: from mail-gx0-f227.google.com ([209.85.217.227]:61981) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MKy6C-0006H5-8h for qemu-devel@nongnu.org; Sun, 28 Jun 2009 13:23:28 -0400 Received: by gxk27 with SMTP id 27so12724885gxk.10 for ; Sun, 28 Jun 2009 10:23:27 -0700 (PDT) Message-ID: <4A47A70B.7070806@codemonkey.ws> Date: Sun, 28 Jun 2009 12:23:23 -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> <4A44CB74.1070808@codemonkey.ws> <4A44E2F3.8050804@codemonkey.ws> <4A476C60.1080609@redhat.com> In-Reply-To: <4A476C60.1080609@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: > On 06/26/2009 06:02 PM, Anthony Liguori wrote: >> # v1 -> v2 >> # o allow integer in symbol names (C-style) >> # o allow negative integer/floats >> # o no newlines in strings >> # o one value per response_data line >> >> __skip__: [ \t]+ >> >> symbol: [A-Za-z_\-][A-Za-z_\-0-9]* >> >> decimalinteger: (-)?[1-9][0-9]+ >> > > Traditionally, 0 is recognized as an integer. >> hexinteger: 0x[0-9]+ >> > > [a-fA-f] I have an updated grammer that has both of these fixes. >> float: (-)?[0-9]+\.[0-9]+ >> > > 5, 3., .10, 1e9 are all floats. I was following JSON style floats as opposed to C float. C floats are irregular and difficult to parse with an automatic parser. If we care, it's worth doing correctly though. >> string: \"([^\"\\\n]|(\\[0-9][0-9][0-9]))*\" | symbol >> > > I think json recognises 'blah' but not symbol. Also it may recognize > other escapes. We can drop symbol. The original intention was to output format similar to what we have today but we're pretty far from that now. > It's important to allow clients to use json emitters so they can > construct a dict and throw it at qemu, similarly to parse qemu results. > >> arg_list: value arg_list? >> >> command: symbol arg_list? '\n' >> > > Better to use a dictionary for the argument list (more > self-documenting, easier expansion). Verses a list? I'm not sure a dict fits the current QEMU model very well. How would you propose fitting it into the current monitor infrastructure? > I'd also adopt jsonrpc's request and id attributes, they allow async > commands and remove the need for any specialized parsing. I think command tagging is a very good thing to do. >> response_status: ('+' | '-') number string? '\n' >> response_data: '=' value '\n' >> async_msg: '*' arg_list '\n' >> >> > > Similarly, return a value that contains message type, id, and return > value. I think command outputs are basically return values. What's nice about the current QMP proposal is that we're basically returning tuples. > I think it's fine to drop jsonrpc as the standard (but retain its > features) and just adopt json for encoding. Yeah, I think if we focus on defining a grammar and semantics, if it happens to look like JSON, I don't really care. I just don't want to adopt the baggage of json and particularly json-rpc. Regards, Anthony Liguori