qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file
Date: Mon, 29 Jun 2009 09:04:33 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]