From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35882) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIyIp-0000H9-Q0 for qemu-devel@nongnu.org; Thu, 27 Feb 2014 05:35:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIyIi-0002t8-F8 for qemu-devel@nongnu.org; Thu, 27 Feb 2014 05:34:55 -0500 Message-ID: <530F14C2.2050808@suse.de> Date: Thu, 27 Feb 2014 11:34:42 +0100 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1392904246-15575-1-git-send-email-aik@ozlabs.ru> <1392904246-15575-4-git-send-email-aik@ozlabs.ru> <530609F9.1060105@redhat.com> In-Reply-To: <530609F9.1060105@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of /machine List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Alexey Kardashevskiy , qemu-devel@nongnu.org Cc: qemu-ppc@nongnu.org, Alexander Graf Am 20.02.2014 14:58, schrieb Paolo Bonzini: > Il 20/02/2014 14:50, Alexey Kardashevskiy ha scritto: >> From: Paolo Bonzini >> >> This is a first step towards QOMifying /machine. >> >> Signed-off-by: Paolo Bonzini >=20 > The patch was originally mine, so I could get it in if Andreas wants me > to handle patches 2-3. But for anyone else it would be missing your > S-o-b line. With this patch I have been plagued by doubts of whether we can run into a race of creating /machine through qdev_get_machine() via command line option handling or whatever other code paths. I'm at a conference and did not find time yet to test this out - if you two could investigate and clarify, that would be helpful in moving forward. Also I thought that someone else had looked into replacing the whole of machine_init and QEMUMachine with QOM infrastructure? Anyway it was an idea that I once had, Anthony didn't like at first and then someone else (Luiz?) convinced Anthony to do it after all but then somehow it got stuck with no patches posted... The discussed approach was instead of creating a type in machine init depending on some QEMUMachine::class_name, always create the type. But either approach conflicts with creating /machine as Container type, as mentioned above. If we go with such an interim solution then at least qdev.c needs to grow an assert. Regards, Andreas >=20 > Paolo >=20 >> --- >> include/hw/boards.h | 1 + >> vl.c | 5 +++++ >> 2 files changed, 6 insertions(+) >> >> diff --git a/include/hw/boards.h b/include/hw/boards.h >> index c2096e6..8640272 100644 >> --- a/include/hw/boards.h >> +++ b/include/hw/boards.h >> @@ -29,6 +29,7 @@ struct QEMUMachine { >> const char *name; >> const char *alias; >> const char *desc; >> + const char *class_name; >> QEMUMachineInitFunc *init; >> QEMUMachineResetFunc *reset; >> QEMUMachineHotAddCPUFunc *hot_add_cpu; >> diff --git a/vl.c b/vl.c >> index 01ab7e4..b300721 100644 >> --- a/vl.c >> +++ b/vl.c >> @@ -4034,6 +4034,11 @@ int main(int argc, char **argv, char **envp) >> qtest_init(qtest_chrdev, qtest_log); >> } >> >> + if (machine->class_name) { >> + Object *m =3D object_new(machine->class_name); >> + object_property_add_child(object_get_root(), "machine", m, >> NULL); >> + } >> + >> machine_opts =3D qemu_get_machine_opts(); >> kernel_filename =3D qemu_opt_get(machine_opts, "kernel"); >> initrd_filename =3D qemu_opt_get(machine_opts, "initrd"); >> >=20 >=20 --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg