From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37545) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WvKfe-0004sV-Hh for qemu-devel@nongnu.org; Fri, 13 Jun 2014 02:09:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WvKfZ-0005wQ-NC for qemu-devel@nongnu.org; Fri, 13 Jun 2014 02:09:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55855) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WvKfZ-0005wB-Ei for qemu-devel@nongnu.org; Fri, 13 Jun 2014 02:08:57 -0400 Date: Fri, 13 Jun 2014 03:08:52 -0300 From: Eduardo Habkost Message-ID: <20140613060852.GE3306@otherpad.lan.raisama.net> References: <1402554144-17545-1-git-send-email-ehabkost@redhat.com> <20140612081349.GA19816@redhat.com> <20140612103729.1a1417fd@nial.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140612103729.1a1417fd@nial.usersys.redhat.com> Subject: Re: [Qemu-devel] [RFC] pc: Register machine classes directly instead of using QEMUMachine List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: Marcel Apfelbaum , "Michael S. Tsirkin" , qemu-devel@nongnu.org, Don Slutz , Alexander Graf , Anthony Liguori , Andreas =?iso-8859-1?Q?F=E4rber?= On Thu, Jun 12, 2014 at 10:37:29AM +0200, Igor Mammedov wrote: > On Thu, 12 Jun 2014 11:13:49 +0300 > "Michael S. Tsirkin" wrote: > > > On Thu, Jun 12, 2014 at 03:22:24AM -0300, Eduardo Habkost wrote: > > > This is a (mostly) blind and mechanical conversion of the PC QEMUMachine > > > definitions to corresponding class registration code. > > > > > > Having the PC code converted to pure QOM registration code will help us > > > move PC-specific machine state that is currently held in static > > > variables inside PC machine objects, and reduce duplication between > > > pc_piix.c and pc_q35.c. > > > > > > Signed-off-by: Eduardo Habkost > > > --- > > > hw/i386/pc.c | 13 ++ > > > hw/i386/pc_piix.c | 473 +++++++++++++++++++++++++++++++++++---------------- > > > hw/i386/pc_q35.c | 171 +++++++++++++------ > > > include/hw/i386/pc.h | 20 ++- > > > 4 files changed, 465 insertions(+), 212 deletions(-) > > > > Hmm amount of boilerplate code seems to have doubled. > > Can we find a solution that does away with code duplication? > > Here's one idea: create one giant array with all necessary data, look it > > up by name at runtime and fill everything in. > > Not sure it's going to work out but might be worth a try. > It's not quite QOMish way, > making version-ed classes nested should reduce amount of boiler plate > and make it easier to read/write. > And if machines are made nested then we should also rethink usage/get rid of > PC_COMPAT_* macros-es utilizing nesting provided by class hierarchy. > > This patch could serve as an intermediate step to remove usage of QEMUMachine though. I am working to make only one hierarchy/nesting structure (class_init hierarchy). Today we have the same hierarchy/nesting pattern duplicated in multiple levels: * PC_COMPAT_* (compat_props) nesting * pc_compat_*() function nesting * pc_init*() function duplication (all with the same compat+pc_init1() pattern) * QEMUMachine/PC_*_MACHINE_OPTIONS nesting/duplication On my work in progress branch I've moved all hierarchy/nesting to class_init, except for pc_compat_*(), which is still necessary in a few cases because of the CPUID compat stuff. My goal is to get all machine-types declared using only a class_init + TypeInfo pair, and nothing else. That should also make us stop creating new compat global variables on every release. :) WIP can be seen at: https://github.com/ehabkost/qemu-hacks/commits/work/pc-machine-class Code now looks like this: https://github.com/ehabkost/qemu-hacks/blob/24398f32268b333354d850da7437c1db263891ff/hw/i386/pc_piix.c I'm not submitting an RFC right now because I need some sleep first, but I plan to send one tomorrow. I plan to addres the piix/q35 code duplication too. It should be much easier to eliminate duplication now that we can have PC-specific machine-type information in a PCMachineClass struct, and PC-specific machine state information in a PCMachineState struct. -- Eduardo