[libvirt] [Qemu-devel] [PATCH v4 4/5] qmp: full introspection support for QMP
Fam Zheng
famz at redhat.com
Wed Jan 29 08:12:23 UTC 2014
On Tue, 01/28 06:58, Eric Blake wrote:
> On 01/28/2014 04:14 AM, Paolo Bonzini wrote:
>
> >> Let's see the feedback of Eric.
> >
> > Eric's feedback is certainly useful, but I think we need to look at it
> > from the QEMU perspective more than the libvirt perspective.
> >
> > Passing the raw schema and letting libvirt parse it is a Really Bad idea
> > from the QEMU perspective, in my opinion, even if it means a little more
> > work now and even if libvirt is willing to add the parser.
>
> Libvirt wants to parse formal qapi, not pseudo-JSON. I still have on my
> to-do list to read the v4 schema and make sure that libvirt can live
> with it.
>
> >
> > First and foremost, the current "pseudo-JSON" encoding of the schema is
> > nothing but a QEMU implementation detail. The "pseudo-JSON" syntax
> > definitely shouldn't percolate to the QAPI documentation. Using normal
> > QAPI structs means that the normal tool for documentation
> > (qapi-schema.json doc comments) applies just as well to QAPI schema
> > introspection
>
> Agreed - I definitely want the output of the query command to be fully
> described by qapi. Which means we DO have to convert from the
> pseudo-JSON of the qapi file into the final formal qapi format. But the
> conversion is known at code generation time, so you should do it as part
> of your python code generator, and not repeat the conversion at runtime
> in the C code. That is, the C code should have everything already split
> out into the data structures it needs to just output the qapi structure
> as documented for the formal qapi definition.
>
Yes, that's exactly what I mean.
If we use python to generate code for qobject_to_dataobj() or even generate
object_to_$type() for each qapi type, the C code needed will be minimal anyway.
Thanks,
Fam
More information about the libvir-list
mailing list