From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46465) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WS3lB-00085I-F1 for qemu-devel@nongnu.org; Mon, 24 Mar 2014 08:13:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WS3l5-0007Dj-Ep for qemu-devel@nongnu.org; Mon, 24 Mar 2014 08:13:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:9853) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WS3l5-0007DW-6W for qemu-devel@nongnu.org; Mon, 24 Mar 2014 08:13:39 -0400 Message-ID: <1395663180.2354.4.camel@localhost.localdomain> From: Marcel Apfelbaum Date: Mon, 24 Mar 2014 14:13:00 +0200 In-Reply-To: <53300E7D.8080501@suse.de> References: <1395327676-29753-1-git-send-email-imammedo@redhat.com> <1395327676-29753-4-git-send-email-imammedo@redhat.com> <1395587617.5673.55.camel@localhost.localdomain> <53300E7D.8080501@suse.de> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC 3/8] pc: prepare PC for custom machine state List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?ISO-8859-1?Q?F=E4rber?= Cc: mst@redhat.com, qemu-devel@nongnu.org, vasilis.liaskovitis@profitbricks.com, aliguori@amazon.com, pbonzini@redhat.com, Igor Mammedov On Mon, 2014-03-24 at 11:52 +0100, Andreas F=C3=A4rber wrote: > Am 23.03.2014 16:13, schrieb Marcel Apfelbaum: > > On Thu, 2014-03-20 at 16:01 +0100, Igor Mammedov wrote: > >> Signed-off-by: Igor Mammedov > >> --- > >> hw/i386/pc.c | 26 ++++++++++++++++++++++++++ > >> hw/i386/pc_piix.c | 34 +++++++++++++++++----------------- > >> hw/i386/pc_q35.c | 10 +++++----- > >> include/hw/i386/pc.h | 14 ++++++++++++++ > >> 4 files changed, 62 insertions(+), 22 deletions(-) > >> > >> diff --git a/hw/i386/pc.c b/hw/i386/pc.c > >> index e715a33..e0bc3a2 100644 > >> --- a/hw/i386/pc.c > >> +++ b/hw/i386/pc.c > >> @@ -1413,3 +1413,29 @@ void ioapic_init_gsi(GSIState *gsi_state, con= st char *parent_name) > >> gsi_state->ioapic_irq[i] =3D qdev_get_gpio_in(dev, i); > >> } > >> } > >> + > >> +void qemu_register_pc_machine(QEMUMachine *m) > > I am not so comfortable with this approach because > > every subsystem (e.g pc) will have to duplicate the > > "register machine" code until the conversion from > > QEMUMachine to MachineClass is over. (which I hope > > it will not take too much time) > >=20 > > I propose a patch already in the list which does that > > automatically by moving this logic into hw/core/machine.c . > > In this way it will be much less code "touched" during conversion.=20 > >=20 > > Andreas, did you have anything against the usage of 'class_base_init'= ? >=20 > Yes, I do, .class_base_init is wrong for this, it would be .class_init; > but please avoid making a base class' .class_init (or .class_base_init) > depend on a subtype specifying .class_data. Got it, thanks >=20 > I believe I asked you to post patches that finish your conversion so > that MachineClass no longer needs this pointer to QEMUMachine and > actually uses the fields you already prepared. In my mind the next > logical step of QOM'ification is to have each machine specify what is > now in a QEMUMachine struct in its own type's class_init, then there is > no duplication of such a general assignment any more. Yes, this is exactly what I am working on right now, I am going to work on both 'QemuOpts -> MachineState properties' and QEMUMachine elimination. Sorry, I've been hold back by other issues until now :) Thanks, Marcel =20 >=20 > Since this patch is for one machine only, I would much prefer to have > the PC duplicate the class_init like we did for sPAPR machine > (hw/ppc/spapr.c) over exposing the class_init across files - if this > series cannot wait to be ordered after the machine series. >=20 > Regards, > Andreas >=20