From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MKHzI-0006ya-My for qemu-devel@nongnu.org; Fri, 26 Jun 2009 16:25:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MKHzD-0006sg-VN for qemu-devel@nongnu.org; Fri, 26 Jun 2009 16:25:32 -0400 Received: from [199.232.76.173] (port=52338 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MKHzD-0006sa-PY for qemu-devel@nongnu.org; Fri, 26 Jun 2009 16:25:27 -0400 Received: from mail-ew0-f211.google.com ([209.85.219.211]:57012) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MKHzD-0003JP-Ac for qemu-devel@nongnu.org; Fri, 26 Jun 2009 16:25:27 -0400 Received: by ewy7 with SMTP id 7so3352951ewy.34 for ; Fri, 26 Jun 2009 13:25:26 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4A45232F.50306@codemonkey.ws> References: <4A412339.5000109@redhat.com> <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> <5b31733c0906261036o272bcd8xffc0f2e209b778a5@mail.gmail.com> <4A45232F.50306@codemonkey.ws> Date: Fri, 26 Jun 2009 22:25:25 +0200 Message-ID: <5b31733c0906261325ye5fe937wea277c2d87ccd1e1@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 9:36 PM, Anthony Liguori wro= te: > Filip Navara wrote: >> >> On Fri, Jun 26, 2009 at 5:02 PM, Anthony Liguori >> wrote: >> > > >> 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) > > Perhaps you mean LR(1) (i.e. something that can be understood by yacc). > =A0When writing parsers by hand, I tend to prefer recursive decent which > easily handles LL(k). I meant LL(1). Nevertheless I realized that it's easy to write a lexer and LL(1) parser given this grammar, so ignore this objection. I prefer to write my parsers by hand instead of using yacc or other tools as long as the grammar is simple enough. > Fortunately, this grammar is very simple and can be reasonable converted = to > LR(1). > >> =A0and not >> all floats can be represented (eg. NaN). > > I'm not sure that's so important. =A0JSON doesn't support NaN. It may not be important now, but I consider it important to get the syntax right the first time. Adding and extending commands to existing implementation is easy (or easier at least) and can be done in backward-compatible way if the syntax of the protocol doesn't change between versions. What JSON does or doesn't support is irrelevant here, most platforms QEMU runs on use IEEE 754 floats and if you want to express them in the syntax then express all of their features - Inf, NaN and exponents (maybe I forgot something). The benefit is that you can use printf functions to output them if the syntax matches what C uses. >> =A0String is underdefined - does >> the syntax represent bytes or characters? If characters then the \nnn >> syntax is insufficient. > > Strings are UTF-8. =A0Based on the definition of string, the only thing > needing escaping is ", \\, and \n. =A0Anything else is just cosmetic. =A0= My > intention was for \nnn to be a single octal byte as an escape. =A0You cou= ld > certainly use multiple escape sequences to encoding a large UTF character= . I guess you mean that the "string" in grammar is sequence of bytes. These bytes should be interpreted as UTF-8 characters then. Note that this is very important to specify. For example the GREEK CAPITAL LETTER PI is unicode code point 928. If the "string" syntax was meant to represent characters I would expect "\928" to refer to single character string with PI being the character, on the other hand in byte-based UTF-8 string you'd write "\206\160". > >> =A0There's no syntax for binary data which may >> eventually be required (FDT machine description), but that can be >> relatively easily added with something like >> > > I don't think binary data is a requirement. =A0An FDT should be transmitt= ed as > a tree, not as a binary blob. =A0You could also transmit binary as a list= of > bytes though. You can transmit it as list of bytes and it's woefully inefficient. I gave the FDT as an example, but I believe that binary data may be needed in future for one purpose or another. The monitor already provides a way to dump guest memory and I see no reason to not transfer it using some "binary" encoding. > > Regards, > > Anthony Liguori > Regards, Filip Navara