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

[Avi Kivity <avi@redhat.com>]

On 06/29/2009 03:42 AM, Anthony Liguori wrote:
> Avi Kivity wrote:
>> First, I would like to consider the protocol mostly from the point of 
>> view of clients, not qemu, and certainly not current qemu code.  
>> There is only one qemu, but many clients.  Code problems can be 
>> solved tomorrow, but interface problems remain forever.
>
> I'm trying to consider both.  We need something that we can get into a 
> robust state in 6 months.  I don't want to undertake a massive effort 
> that will require major changes because history shows that we'll end 
> up with something that doesn't really do the job.

History also shows that band aids rarely work, that trying to reinvent 
wheels leads to unusual shapes, and that we're pretty bad at predicting 
future needs.

>> Second, I think it fits quite nicely.  Positional arguments are nasty 
>> when you have many of them, especially when some are optional.  And 
>> we already support dictionaries: -drive file=blah,cache=none.  We 
>> make a dictionary interface, and have both the command line parser 
>> and the monitor json thing implement it.
>
> It a fair bit of complexity but I don't think it's too problematic.  
> The current monitor abstraction doesn't have a mechanism to define 
> names of arguments but I think it could be added relatively easily 
> although it wouldn't be so elegant (another parameter with comma 
> deliminated names would do the trick).

Instead of 7 callback types you get one callback type with one parameter 
(an object).  We can retain the table driven parsing for the human 
monitor by, for example, changing

     { "memsave", "lis", do_memory_save,
       "addr size file", "save to disk virtual memory dump starting at 
'addr' of size 'size'", },

to
     { "memsave", "address:l,size:i,file:s", do_memory_save,
       "save to disk virtual memory dump starting at 'address' of size 
'size'", },

>>
>> Yes, I meant { 'type': 'respose', 'id': 'foo', 'return': value }.  
>> 'type' is the new =, and 'id' is the tag.  If multiple return values 
>> are needed, value can be a list or dictionary.
>
> I really don't like the syntax you proposed but that's an aesthetic 
> problem.  This is an interface consumed by non humans so I don't think 
> it's worth arguing about something that is just as easily parsed by a 
> computer even if it's hideously ugly :-)

I too prefer looking at the original QMP with hand crafted syntax.  But 
even more I prefer not looking at it, and the more we make it machine 
consumable, the less we have to dig in.

> The main thing missing from the first patchset that this thread has 
> revealed is a formal grammar for the data.  This is an important 
> requirement to ensure that it's reasonably parse-able by both ends.

That's something else gained from json -- someone else has written the 
grammar and made sure it works in real life.


>>>> 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.
>>
>> If 'looks like' == 'compatible with', I agree.
>
> You lost me here.  JSON interoperability cannot be a requirement.  
> Otherwise, we're going to get stuck dealing with all the warts of JSON. 

Look at the top half of http://www.json.org/.  It's remarkably wart free.

> I don't want people to assume they can just use a JSON parser.

Look at the bottom half of http://www.json.org/.  It's remarkably parser 
full.  It means that anyone can get up and running writing a cloud in 
haXe or Fan without studying and implementing the qemu data format.

>
> You seem to have conflicting requirements.   You want JSON 
> compatibility but then you want C-style floats which JSON doesn't 
> support.

According to the json grammar, it supports floats (including exponents), 
except for NaN and Inf.  Personally,  I'm happy to limit qemu to finite 
numbers.

> I don't mind if this ends up looking like JSON, but I don't want to 
> have to enforce that it's remains JSON compatible in the long term.  
> We should have our own grammar that we can version and that people can 
> use as the basis of a client.

That really reduces the attractiveness of the whole thing.  Writing 
parsers and emitters should be an optional part of writing a qemu 
control program, not a required part.


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.