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

[Anthony Liguori]

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