From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MS9Gi-0004Ow-Tr for qemu-devel@nongnu.org; Sat, 18 Jul 2009 08:44:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MS9Ge-0004OU-7o for qemu-devel@nongnu.org; Sat, 18 Jul 2009 08:44:00 -0400 Received: from [199.232.76.173] (port=53664 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MS9Ge-0004OR-0g for qemu-devel@nongnu.org; Sat, 18 Jul 2009 08:43:56 -0400 Received: from mail2.shareable.org ([80.68.89.115]:37193) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MS9Gd-0001KB-Is for qemu-devel@nongnu.org; Sat, 18 Jul 2009 08:43:55 -0400 Date: Sat, 18 Jul 2009 13:43:49 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 2/2] Introduce macro for defining qdev properties Message-ID: <20090718124349.GA9677@shareable.org> References: <1247841685-18495-1-git-send-email-aliguori@us.ibm.com> <4A60D981.5030008@us.ibm.com> <200907172358.43108.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907172358.43108.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Blue Swirl , Anthony Liguori , qemu-devel@nongnu.org, Gerd Hoffman 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