qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] full introspection support for QMP


From: Amos Kong
Subject: Re: [Qemu-devel] [PATCH] full introspection support for QMP
Date: Thu, 4 Jul 2013 11:54:08 +0800
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Jul 02, 2013 at 01:27:32PM -0500, Anthony Liguori wrote:
> Eric Blake <address@hidden> writes:
> 
> > On 07/02/2013 11:01 AM, Paolo Bonzini wrote:
> >>>> Arguably that rule of thumb would apply equally to the QEMU
> >>>> build scripts which already parse qapi-schema.json. It could
> >>>> be possible to normalize qapi-schema.json somewhat to remove
> >>>> this 2-stage parsing if we went down this route.
> >>>
> >>> Indeed, I wouldn't mind a one-time pass over qapi-schema.json to make it
> >>> follow a more rigid format if that made it easier to use it as-is with
> >>> less post-processing.  It won't be very nice to backport such a
> >>> conversion, but I don't know how much distros are planning on
> >>> backporting introspection in the first place.
> >> 
> >> How would the schema look like after this "one-time pass"?
> >> 
> >> This:
> >> 
> >>> [
> >>>          { "name": "protocol",
> >>>            "type": "str" },
> >>>          { "name": "fdname",
> >>>            "type": "str" },
> >>>          { "name": "skipauth",
> >>>            "type": "bool",
> >>>            "optional": true },
> >>>          { "name": "tls",
> >>>            "type": "bool",
> >>>            "optional": true }
> >>> ]
> >> 
> >> Looks quite awful for a human to write and read.
> >
> > Which puts us back in favor of my original argument that keeping
> > qapi-schema.json compact for human use,
> 
> qapi-schema.json is not "for human use".  It's consumed by QAPI.  It
> happens to be reasonably human readable but that's just a happy
> coincidence and because we document and format the heck out of it.
> 
> > while expanding the QMP output
> > to be verbose for machine use, is probably what we'll have to live with.
> >  While it is easy to document shortcuts that the qapi parser can use
> > when converting .json to code, it is harder to require that all other
> > QMP clients must implement those same shortcuts, instead of having
> > things already directly represented.
> 
> qapi-schema.json is valid JSON except for the # style comments.  Those
> are trivial to remove and we could simply post process it.
> 
> Heck, if you use json_parser to parse the file, you'd end up with a list
> of QObjects that could be returned directly via QMP.
 
I like this solution, but QObject is not a defined type in
qapi-schema.json, so we can't assign qobj to return data.
We also need to do "post-processing" to provide prolific
meta-data to management.

# { 'command': 'query-qmp-schema', 'returns': ['QObject'] }

> I don't understand what all this talk of "post-processing" is.

When management gets the raw jaso string, they could not directly use,
post-processing might be:
1) revert the whole schema by itself, replace defined type by complex json
2) process the '*' before typename
3) process json string to get type(command/event/type...),name(command
name, type name, event name), data, returns one by one.
4) etc

> Regards,
> 
> Anthony Liguori

-- 
                        Amos.



reply via email to

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