[Top][All Lists]
[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.
- Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file, (continued)
- Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file, Filip Navara, 2009/06/27
- Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file, Avi Kivity, 2009/06/28
- Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file, Avi Kivity, 2009/06/28
- Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file, Anthony Liguori, 2009/06/28
- Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file, Avi Kivity, 2009/06/28
- Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file, Anthony Liguori, 2009/06/28
- Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file,
Avi Kivity <=
- Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file, Stefano Stabellini, 2009/06/29
- Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file, Anthony Liguori, 2009/06/29
- Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file, Avi Kivity, 2009/06/30
- Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file, Anthony Liguori, 2009/06/30
- Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file, Stefano Stabellini, 2009/06/30
- Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file, Avi Kivity, 2009/06/30
- Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file, Anthony Liguori, 2009/06/30
- Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file, Luiz Capitulino, 2009/06/30
- Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file, Avi Kivity, 2009/06/30
- Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file, Anthony Liguori, 2009/06/30