Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file

[Filip Navara]

On Fri, Jun 26, 2009 at 9:36 PM, Anthony Liguori<address@hidden> wrote:
> Filip Navara wrote:
>>
>> On Fri, Jun 26, 2009 at 5:02 PM, Anthony Liguori<address@hidden>
>> 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).
>  When 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).
>
>>  and not
>> all floats can be represented (eg. NaN).
>
> I'm not sure that's so important.  JSON 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.

>>  String is underdefined - does
>> the syntax represent bytes or characters? If characters then the \nnn
>> syntax is insufficient.
>
> Strings are UTF-8.  Based on the definition of string, the only thing
> needing escaping is ", \\, and \n.  Anything else is just cosmetic.  My
> intention was for \nnn to be a single octal byte as an escape.  You could
> 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".

>
>>  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
>>
>
> I don't think binary data is a requirement.  An FDT should be transmitted as
> a tree, not as a binary blob.  You 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