From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:32888) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rpmsj-0006eh-4U for qemu-devel@nongnu.org; Tue, 24 Jan 2012 15:22:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rpmse-00036B-P9 for qemu-devel@nongnu.org; Tue, 24 Jan 2012 15:22:14 -0500 Received: from e34.co.us.ibm.com ([32.97.110.152]:55132) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rpmse-00035x-Hx for qemu-devel@nongnu.org; Tue, 24 Jan 2012 15:22:12 -0500 Received: from /spool/local by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 24 Jan 2012 13:22:10 -0700 Message-ID: <4F1F12E7.2020309@us.ibm.com> Date: Tue, 24 Jan 2012 14:21:59 -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> In-Reply-To: <4F1F0E2D.2020706@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=E4rbe?= =?ISO-8859-15?Q?r?= , qemu-ppc@nongnu.org, Paul Brook , Aurelien Jarno , Gerd Hoffmann On 01/24/2012 02:01 PM, Jan Kiszka wrote: > On 2012-01-24 20:33, Anthony Liguori wrote: >> This converts three devices because apic and ioapic are subclasses of sysbus. >> Converting subclasses independently of their base class is prohibitively hard. > > Hmm, I think that's more than three... Can you split up? At least per > target or per board/machine. I meant three classes of devices. I don't see a reasonable way to split it up. I put an awful lot of work into just splitting things up at this level. I know it's a big patch but at the same time, the changes are entirely mechanical so reviewing shouldn't be that bad. > > Also, I see a lot of programmatic initialization and a lot of repeating > patterns (specifically regarding trivial class initialization) - there > is no better alternative? Not really, no. It looks bad now because you have DeviceInfo still. Once DeviceInfo goes away, all of the initialization will happen in the class_init function. The design of QOM is such that a lot of what was previously done via declarative structures is now done imperatively. But the code bloat that came in this patch series will decrease significantly with the next series as we eliminate DeviceInfo. Regards, Anthony Liguori > Jan