qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4 24/26] qidl: add QAPI-based code generator


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v4 24/26] qidl: add QAPI-based code generator
Date: Fri, 19 Oct 2012 05:01:03 -0400 (EDT)

> > >> In general, if struct X is QIDL_DECLAREd and only has
> > >> q_immutable
> > >> fields, it can be taken as q_immutable.  Hence for example the
> > >> base
> > >> class should not need any decoration; ISADevice will be seen as
> > >> q_immutable, but PCIDevice will be seen as serialized.  But even
> > >> if a
> > >> struct is not QIDL_DECLAREd, it  should be possible to apply a
> > >> tag to a
> > >> typedef, and have it always applied to the members.
> > 
> > Hmm, this wasn't the best choice of words.  What I actually meant
> > was "to apply a tag to a typedef, and have it always applied to members
> > of that type in other structs".  Like
> > 
> > typedef struct Notifier Notifier q_immutable;
> 
> This would be really nice, but the parser is gonna need more hardening
> before we can remove it's "scan for lines beginning with QIDL_START*
> and parse what we expect to come afterward" behavior. There's also
> build time implications. An alternative I'm considering is:
> 
> typedef struct Notifier Notifier;
> 
> QIDL_DECLARE_PUBLIC(Notifier, q_immutable) {
>     ...
> }
> 
> This will make all the fields q_immutable by default (individual fields
> can override it in the future when the need arises). Then we teach the
> code generator to drop serialization for any struct fields who don't
> have any serializeable fields (mainly to avoid a bunch of nil fields
> in the serialized code (e.g. 'notifier1': {})).
> 
> Seem reasonable?

Optimal, no... reasonable, yes. :)

Paolo



reply via email to

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