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