From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MWtcB-0004KV-AP for qemu-devel@nongnu.org; Fri, 31 Jul 2009 11:01:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MWtc6-0004Js-R6 for qemu-devel@nongnu.org; Fri, 31 Jul 2009 11:01:46 -0400 Received: from [199.232.76.173] (port=59676 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MWtc6-0004Jp-LU for qemu-devel@nongnu.org; Fri, 31 Jul 2009 11:01:42 -0400 Received: from mx2.redhat.com ([66.187.237.31]:60722) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MWtc6-0002BA-2Q for qemu-devel@nongnu.org; Fri, 31 Jul 2009 11:01:42 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n6VF1UR2012438 for ; Fri, 31 Jul 2009 11:01:30 -0400 Message-ID: <4A730747.9000306@redhat.com> Date: Fri, 31 Jul 2009 17:01:27 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RfC PATCH 2/2] qdev/prop: convert pci.c to helper macros. References: <1249045499-10973-1-git-send-email-kraxel@redhat.com> <1249045499-10973-3-git-send-email-kraxel@redhat.com> <20090731143251.GA9233@redhat.com> In-Reply-To: <20090731143251.GA9233@redhat.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: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org On 07/31/09 16:32, Michael S. Tsirkin wrote: > Unfortunately there's still duplication - in the macro definition: > DEFINE_PROP_DEFAULT(_n, _s, _f, _d, qdev_prop_uint64, uint64_t) It has to be somewhere ... > Full self-contained toy example below, in case you want to play with > my idea some more: Can you create a working patch against qemu next time please? > #include > #include > > struct prop { > long long type; > }; This is the PropertyInfo aequivalent, right? Note we are using the very same PropertyInfo struct for all property types we have, thus your idea simply doesn't work. We could use a different struct for each type. That wouldn't solve the fundamental issue though, it would just shift it to another place. cheers, Gerd