From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MRtgV-0007KW-1b for qemu-devel@nongnu.org; Fri, 17 Jul 2009 16:05:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MRtgQ-0007Aq-2N for qemu-devel@nongnu.org; Fri, 17 Jul 2009 16:05:34 -0400 Received: from [199.232.76.173] (port=60414 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MRtgP-0007AS-Ib for qemu-devel@nongnu.org; Fri, 17 Jul 2009 16:05:29 -0400 Received: from e7.ny.us.ibm.com ([32.97.182.137]:55284) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MRtgP-0004p2-1I for qemu-devel@nongnu.org; Fri, 17 Jul 2009 16:05:29 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e7.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n6HJq5O4015783 for ; Fri, 17 Jul 2009 15:52:05 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n6HK5OWL101118 for ; Fri, 17 Jul 2009 16:05:24 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n6HK5NBv026780 for ; Fri, 17 Jul 2009 16:05:24 -0400 Message-ID: <4A60D981.5030008@us.ibm.com> Date: Fri, 17 Jul 2009 15:05:21 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/2] Introduce macro for defining qdev properties References: <1247841685-18495-1-git-send-email-aliguori@us.ibm.com> <1247841685-18495-3-git-send-email-aliguori@us.ibm.com> <200907171833.34167.paul@codesourcery.com> <4A60BEEF.2050601@us.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Gerd Hoffman , Paul Brook , qemu-devel@nongnu.org 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. typedef struct MyDeviceStruct { SysBusDevice parent; /* public */ QDEV_PROP(uint32_t, queue_depth); QDEV_PROP(uint32_t, tx_mitigation_delay); QDEV_PROP(CharDriverState *, chr); } MyDeviceStruct; Normally, we: #define QDEV_PROP(a, b) a b But then we could also do something like: #define QDEV_PROP(a, b) QPROP_CANARY stringify(a) stringify(b) Then run through CPP and grep 'CANARY | typedef struct' and then parse the output to build the table at build time. Of course, we could just do QDEV_PROP like I originally proposed and then if we ever support something other than GCC, we can introduce a CPP post-processor to build the tables at compile time. This is the approach we're taking for constructors after all. -- Regards, Anthony Liguori