From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MRrvZ-0006DE-A7 for qemu-devel@nongnu.org; Fri, 17 Jul 2009 14:13:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MRrvU-00068P-8u for qemu-devel@nongnu.org; Fri, 17 Jul 2009 14:13:00 -0400 Received: from [199.232.76.173] (port=52342 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MRrvU-00068A-07 for qemu-devel@nongnu.org; Fri, 17 Jul 2009 14:12:56 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]:35761) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MRrvT-0001Av-Ga for qemu-devel@nongnu.org; Fri, 17 Jul 2009 14:12:55 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n6HI8dI2023182 for ; Fri, 17 Jul 2009 12:08:39 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n6HIC2Ee218294 for ; Fri, 17 Jul 2009 12:12:05 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n6HIC1XI011731 for ; Fri, 17 Jul 2009 12:12:01 -0600 Message-ID: <4A60BEEF.2050601@us.ibm.com> Date: Fri, 17 Jul 2009 13:11:59 -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> In-Reply-To: <200907171833.34167.paul@codesourcery.com> 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: Paul Brook Cc: Blue Swirl , qemu-devel@nongnu.org, Gerd Hoffman Paul Brook wrote: > I think I agree. Using GCC extensions for error checking (e.g. DO_UPCAST) or > performance (__builtin_clz) is fine, but I'm a reluctant to rely on it for > correct operation. > Practically speaking, we've never supported anything but GCC and I doubt we ever will. In this case, it's an important part of something I'm trying to fix about the current property system. It seems very brittle to me. You have to specify a type in both the state structure and in the property definition. Those two things are very, very far apart in the code. Right now, the rules about type compatible are ill defined which makes it more likely to break beyond simple mistakes. For instance, uint32 is used for uint32_t, int32_t, and int. That seems odd. I also don't like the fact that we mix field type information with display information. I haven't thought about the best solution to this but I think it's either introducing new struct types or adding an optional decorator parameter. The system I'm aiming for looks like this: typedef struct { SysBusDevice parent; /* public */ uint32_t queue_depth; uint32_t tx_mitigation_delay; CharDriverState *chr; /* private */ ... } MyDeviceState; static Property my_device_properties[] = { QDEV_PROP(MyDeviceState, queue_depth), QDEV_PROP(MyDeviceState, tx_mitigation_delay), QDEV_PROP(MyDeviceState, chr), {} }; Where there's a connection between properties and device state fields and there's no duplicate type information. That means that for the most part, the rules of type compatible can be ignored by most users. I'd like to see most uses of QDEV_PROP_NAME eliminated by renaming variables and accepting '-' in place of '_'. We'll always need a way to accept default values. 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. -- Regards, Anthony Liguori