qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4 04/10] qapi: Emit implicit structs in generat


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v4 04/10] qapi: Emit implicit structs in generated C
Date: Tue, 8 Mar 2016 22:42:43 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

On 03/08/2016 12:09 PM, Markus Armbruster wrote:

> 
>> I think what would sway me over the fence is looking at some of our
>> constructs: for example, qapi-types.py has gen_object() which it now
>> calls recursively.  When called directly from visit_object_type(), we
>> have all the pieces; when called from visit_alternate_type(), we have to
>> create a 1-element members array; and when called recursively, we have
>> to manually explode base into the four pieces.
> 
> What could be improved if we changed visit_object_type() to take a
> QAPISchemaObjectType instead of name, info, base, members, variants?
> 
> I believe we'd leave gen_object() unchanged to keep
> visit_alternate_type() simple.
> 
> Here's a different one: we could drop visit_object_type_flat().

Indeed. But I'd rather get v5 of this series out sooner rather than
later, so I'll save the change for a later day.


>>>
>>> Uh, these are "always reserved for use as identifiers with file scope"
>>> (C99 7.1.3).  I'm afraid we need to use the q_ prefix.

Seems doable. We already reserved q_ for ourselves (commit 9fb081e0), so
far using it mainly by c_name.  There's still the risk that c_name adds
q_ onto something ticklish which then clashes with our use of q_ on an
implicit type for something else; except that we haven't declared 'obj'
as ticklish.

> I feel awful generating >100KiB of code that gets included pretty much
> every time we compile anything.  Perhaps the proper fix for that is to
> find out *why* we include qapi-types.h so much, then figure out how to
> include it much, much less.
> 
> Here's a guilty one: error.h.  I believe it includes qapi-types.h just
> for QapiErrorClass.  I guess it's only in the QAPI schema to have
> QapiErrorClass_lookup[] generated.  I'd gladly maintain those nine(!)
> lines of code manually if it helps me drop >100KiB of useless code from
> many (most?) compiles.

Commit 13f59ae predates my work on qapi, but I think you're right that
error.h including qapi-types.h is a big offender and appears to do so
solely for ErrorClass.  But how about as a followup series, so that v5
gets out the door sooner.

> 
> Another one are builtin QAPI types.  A few headers want them.  We could
> put them into a separate header instead of generating them into
> qapi-types.h.  Could also enable getting rid of the ugly "spew builtins
> into every header, but guard them with #ifdeffery" trick.

In that same series.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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