Re: [Qemu-devel] [PATCH RFC 00/21] Modularize generated QAPI code

[Markus Armbruster <armbru@redhat.com>]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Fri, Feb 02, 2018 at 02:03:15PM +0100, Markus Armbruster wrote:
>> Our qapi-schema.json is composed of modules connected by include
>> directives, but the generated code is monolithic all the same: one
>> qapi-types.h with all the types, one qapi-visit.h with all the
>> visitors, and so forth.  These monolithic headers get included all
>> over the place.  In my "build everyhing" tree, adding a QAPI type
>> recompiles about 4500 out of 4800 objects.
>> 
>> Nobody would write such monolithic headers by hand.  It stands to
>> reason that one shouldn't generate them, either.
>> 
>> This series' basic idea is to split up generated headers to mirror the
>> schema's modular structure: one header per module.  That way, you can
>> include just what you need.
>> 
>> The series is RFC for a number of reasons:
>> 
>> * The split is implemented only for qapi-types.h.  That one should
>>   provide the biggest benefits, though.
>> 
>> * There's a bit of code duplication.
>> 
>> * I haven't re-read my patches, yet.
>> 
>> Even in this incomplete state, the compile-time improvements can be
>> massive.  Before this series, any QAPI schema change recompiles some
>> 4500 out of 4800 objects in my "build everything" tree.  Afterwards,
>> adding a type to qapi/migration.json recompiles less than 400, adding
>> a QMP event recompiles less than 200, and a documentation change no
>> longer recompiles anything.
>
> Having gone through the same exercise for trace.h, I very much welcome
> this effort for QAPI too !

Thanks!

> If I consider the crypto stuff I maintain, the QAPI definitions are
> in qapi/crypto.json.
>
> From my POV, I feel it would be natural to have them move to instead
> be at  crypto/qapi.json, and have the generated headers/source files be
> crypto/qapi-types.h, crypto/qapi-visit.h, etc.
>
> This would mirror what we did with tracing, crypto/trace-events, and
> generating crypto/trace*.{c,h}

Make sense from a QAPI-using subsystem's point of view.

However, from the QAPI/QMP external interface point of view, keeping the
interface in one place also makes sense.  Not least for ease of grep
(I'm admittedly biased there).

If we decide we want to move the QAPI schema sub-modules anyway, we can
do that on top.