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

[Filip Navara <filip.navara@gmail.com>]

On Fri, Jun 26, 2009 at 5:02 PM, Anthony Liguori<anthony@codemonkey.ws> wrote:
> Anthony Liguori wrote:
>>
>> 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.
>>
> Here's an updated grammar.
>
> One benefit of using our own grammar over just JSON-RPC that is line based
> is that lines form discrete PDUs.  If you wanted to implement a JSON-RPC
> parser, you would have to be able to either invent your own PDU transmission
> mechanism or rely on the JSON parser to determine message boundaries.  Since
> the later is likely to be a recursive decent parser, this is difficult to
> work into an asynchronous client library.  The 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 sure
> that the recursion will complete without requiring more data.
>
> Regards,
>
> Anthony Liguori
>
> # QMP 1.0
>
> # 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]+
> 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: '=' 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 := 'B' base64-string
base64-string := \" ([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 {<size>}
C: + Ok, send the data
S: <binary data of the announced size>

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