From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MRwOC-0007DT-5c for qemu-devel@nongnu.org; Fri, 17 Jul 2009 18:58:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MRwO7-0007Cx-8Q for qemu-devel@nongnu.org; Fri, 17 Jul 2009 18:58:51 -0400 Received: from [199.232.76.173] (port=41070 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MRwO7-0007Cs-4x for qemu-devel@nongnu.org; Fri, 17 Jul 2009 18:58:47 -0400 Received: from mx20.gnu.org ([199.232.41.8]:37337) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MRwO6-0002CI-M6 for qemu-devel@nongnu.org; Fri, 17 Jul 2009 18:58:46 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MRwO5-0004dJ-N8 for qemu-devel@nongnu.org; Fri, 17 Jul 2009 18:58:45 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH 2/2] Introduce macro for defining qdev properties Date: Fri, 17 Jul 2009 23:58:41 +0100 References: <1247841685-18495-1-git-send-email-aliguori@us.ibm.com> <4A60D981.5030008@us.ibm.com> In-Reply-To: <4A60D981.5030008@us.ibm.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907172358.43108.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Blue Swirl , Anthony Liguori , Gerd Hoffman 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. Paul