Re: [Qemu-devel] [PATCH 2/2] Introduce macro for defining qdev properties

[Jamie Lokier <jamie@shareable.org>]

Paul Brook wrote:
> On Friday 17 July 2009, Anthony Liguori wrote:
> > Blue Swirl wrote:
> > >> I'm not sure how to do this without GCC extensions.  We could
> > >> potentially add macro decorators and use a sparse-like tool to extract
> > >> property lists automatically from device state.
> > >
> > > Then there is the template way:
> >
> > Yes, I also considered that.
> >
> > Another option would be comment decorators along with a post-processor.
> 
> QDEV_PROP(uint32, field) and QDEV_PROP_UINT32(field) are pretty much 
> isomorphic. Both cases it can be implemented with standard C preprocessor 
> functionality, and maybe GCC extensions for compile time checking. I don't 
> mind requiring gcc for debug builds and consistency checking.
> 
> There is some duplication, with the type specified in both the property macro 
> and the structure member definition. As long as we have compile time checking 
> I'm willing to accept that.
> 
> 
> However I don't think it is possible to implement QDEV_PROP(field) without 
> fancy GCC extensions or fairly invasive preprocessing. It feels a little too 
> clever for comfort, verging on a custom device description langage.

In (hopefully) ANSI-portable C code which performs a very similar
function, I got it down to OPTION_SIGNED("name", var),
OPTION_UNSIGNED("name", var), OPTION_BOOL("name", var),
OPTION_STRING("name", var), for the major non-compound types.

For enums, OPTION_ENUM("name", var, ), ENUM("this", THIS),
ENUM("that", THAT), for good value checking, or OPTION_ENUM("name",
var, "this|that|other") if you're confident that the numeric
values are sequential.

Lists, vectors, bounds checks and predicates are easily supplied.

I suspect with C99 varargs macros and compound initialisers (both
supported by GCC) it can be rather tidier, but I didn't explore that.

Then OPTION_SIGNED_RANGE("name", var, 0, 99) and OPTION_UNSIGNED_RANGE
provide nice bounds checks in many cases.

I never found a way to eliminate the SIGNED/UNSIGNED/FLOAT/BOOL
distinction portably, due to the constant-expression rules for global
initialisers.

-- Jamie