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: Tue, 30 Jun 2009 08:37:06 +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 11:23 PM, Anthony Liguori wrote:
Avi Kivity wrote:
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 really disagree

Writing parsers and emitters should be a required part of writing a qemu control program?


Whatever we do for QMP, it will not be enabled for 0.11 so we have 6 months to get it right. In the interest of moving forward and writing patches instead of emails, here's what I'm thinking:

1) Update the QMP patches to support return values for monitor commands
2) Update patches to support structured command output
3) Update the patches to support higher level data types (like lists and dictionaries) 4) For whatever the emission format is, provide a regular grammar to parse that output

I will commit a patch series that meets these goals.

We have six months so you'll commit some unreviewed patches now?

This is deeply dissatisfying.

Given a regular grammar, it's extremely easy to convert to outputting JSON, XML, or whatever. We can keep arguing about whether JSON is the right format long term. However, I don't want the useful work of conversing monitor commands to satisify 1-3 to be held up by arguments about the emission format which is largely unrelated to the command conversions.

We can certainly get consensus on some things earlier. I don't see the need to commit without review though.

--
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]