From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46287) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rq41s-0006Fb-Ny for qemu-devel@nongnu.org; Wed, 25 Jan 2012 09:40:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rq41i-0006Rk-Uh for qemu-devel@nongnu.org; Wed, 25 Jan 2012 09:40:52 -0500 Message-ID: <4F201464.1010303@codemonkey.ws> Date: Wed, 25 Jan 2012 08:40:36 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1327433600-7403-1-git-send-email-aliguori@us.ibm.com> <1327433600-7403-28-git-send-email-aliguori@us.ibm.com> <4F1F0E2D.2020706@web.de> <4F1F12E7.2020309@us.ibm.com> <4F1F1C28.4040600@web.de> <4F1F1E91.50609@codemonkey.ws> <4F1F233B.8040804@web.de> <4F1F2875.3050509@codemonkey.ws> <4F1F2B77.2020703@web.de> <4F1F38B6.7000506@codemonkey.ws> <4F1FBF31.2020002@web.de> <4F200AEE.20504@codemonkey.ws> <4F201077.1000906@web.de> In-Reply-To: <4F201077.1000906@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 27/28] sysbus: apic: ioapic: convert to QEMU Object Model List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Peter Maydell , "Michael S. Tsirkin" , qemu-devel@nongnu.org, Alexander Graf , Blue Swirl , =?ISO-8859-15?Q?Andreas_F=E4rber?= , qemu-ppc@nongnu.org, Paul Brook , Aurelien Jarno , Gerd Hoffmann On 01/25/2012 08:23 AM, Jan Kiszka wrote: > On 2012-01-25 15:00, Anthony Liguori wrote: >> On 01/25/2012 02:37 AM, Jan Kiszka wrote: >>> On 2012-01-25 00:03, Anthony Liguori wrote: >>>> They're exactly the same size (16 lines). If you embed TypeInfo into >>>> DeviceTypeInfo, and introduce a Device specific type registration >>>> function, then you could do: >>>> >>>> static DeviceTypeInfo my_device_type_info = { >>>> .type.name = TYPE_MY_DEVICE, >>>> .type.parent = TYPE_PARENT_DEVICE, >>>> .reset = my_device_reset, >>> >>> And if you introduce some >>> >>> #define TYPE_UNIMPLEMENTED (void *)&dummy_variable >> >> (void *) isn't compatible with integers or function pointers (at least >> not in a portable way). I don't see how they can be compatible since on some platforms sizeof(void (*)(void)) != sizeof(void *). > > The former is true, the latter not. However, if you use pointers in the > TypeInfo structs consistently (const int * etc.), this issue should be > solvable as well. How would you handle PCIDeviceInfo? >> I'm not being dismissive, I've already spent a lot of time trying to >> make it work and have convinced myself that it isn't workable. >> >> If you can show a mechanism that works, I don't mind scripting a mass >> conversion. I'm also fairly confident that a workable solution is going >> to be better than what we have. > > Well, I'm surely not happy having to go through all of the devices > again, even if scripted (scripts tend to neglect some coding style rules > e.g.). But if this change is in a hurry and my concern is the only one, > then let it be. I wouldn't be happy with it either, but in the absence of a concrete counter proposal and given that I've spent a fair amount of time trying to figure this out, I strongly believe we won't need to make the change. I'm happy to be proven wrong though. Regards, Anthony Liguori > > Jan >