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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list