[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 14/22] qapi: add query-version QMP command

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 14/22] qapi: add query-version QMP command
Date: Wed, 09 Mar 2011 08:47:04 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8

On 03/09/2011 08:37 AM, Avi Kivity wrote:
On 03/09/2011 04:11 PM, Anthony Liguori wrote:
(just picking on a patch that has a bit of schema in it)

If you want to see more of the schema in action http://repo.or.cz/w/qemu/aliguori.git/blob/refs/heads/glib:/qmp-schema.json

Thanks. Something a little worrying is the reliance on capitalization and punctuation ( {} vs [] ) do distinguish among the different types of declarations. It's not immediately clear if something is a type, event, or command.

We could do


{ 'type': 'MyType', fields: [['a', 'str'], ['b', 'int'], ['c', 'AnotherType']] }
{ 'event': 'MY_EVENT', 'arguments': [ ... ] }
{ 'command': 'my-command', 'arguments': [ ... ], 'return': ... }


which leaves us room for additional metainformation.

The concern is more about non-qemu consumers of the schema.

Yeah, I dislike it too and I've been leaning towards changing it.

My preference would be:

{ 'type': 'MyType', 'fields': { 'a': 'str', 'b': 'int', 'c': 'AnotherType' } }
{ 'event': 'MY_EVENT', 'arguments': {...} }
{ 'command': 'my-command', 'arguments': {...}, 'returns': 'int' }

I do prefer the dictionary syntax for arguments over a list because a list implies order. Plus I think the syntax is just awkward and a whole lot easier to get wrong (too many/few elements in list).

I don't think I want to make this sort of change just yet. Also note that the schema that will be exposed over the wire is not directly related to the schema we use for code generation.

Something that can be added to the schema are default values for newly added parameters. This way we can avoid an explosion of commands where adding an optional parameter suffices; should be easier for the user to pick the right command and easier for us to document and support.

Adding a parameter to a command, even if the schema specifies a default value, is going to break the C library ABI so it's something we should strongly discourage.

We could add compatibility signatures when we extend a command:

{ 'command': 'x', arguments: [['a', 'str']], return: ...,
   'signatures': { 'x': [], 'x2': ['a'] } }

That lets the wire protocol extend x without introducing a new command, but for libqmp it adds a new x2() API with the new parameter.

I'd rather just not add arguments.

Treating QMP as a C API makes it easier for us to maintain compatibility both internally and externally.


Anthony Liguori

reply via email to

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