From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42812) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vnr4H-0008AR-3O for qemu-devel@nongnu.org; Tue, 03 Dec 2013 09:35:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vnr4B-0003xE-4C for qemu-devel@nongnu.org; Tue, 03 Dec 2013 09:35:17 -0500 Message-ID: <529DEC1A.2030306@suse.de> Date: Tue, 03 Dec 2013 15:35:06 +0100 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1385364460-24332-1-git-send-email-aik@ozlabs.ru> <1385364460-24332-3-git-send-email-aik@ozlabs.ru> <529DA675.8030705@redhat.com> <529DE041.70006@suse.de> <529DE3F0.2050101@redhat.com> In-Reply-To: <529DE3F0.2050101@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 2/5] machine: introduce get_fw_dev_path() callback List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Peter Crosthwaite , Nikunj A Dadhania , Alexey Kardashevskiy , qemu-devel@nongnu.org, qemu-ppc@nongnu.org, Anthony Liguori , Paul Mackerras , =?ISO-8859-1?Q?Herv=E9_Poussineau?= Am 03.12.2013 15:00, schrieb Paolo Bonzini: > Il 03/12/2013 14:44, Andreas F=E4rber ha scritto: >>>> >>>> You can check "if (current_machine && >>>> current_machine->get_fw_dev_path)", and move current_machine from vl= .c >>>> to hw/qdev/core.c. >> Please don't encourage moving random stuff into "core" device code. >> >> If needed, we can easily add a machine.c, but that should remain >> softmmu-only. >=20 > Another solution would be to: >=20 > (1) add an interface which contains "get_fw_dev_path". When > qdev_get_fw_dev_path is called, walk the QOM tree until an object that > implements the interface is found. If none is found, call the bus > implementation as usual. >=20 > (2) in vl.c, add a way for current_machine to override the /machine > object. A 100%-QOMified machine indeed could put a SOC-like Device the= re. >=20 > (3) for spapr, define the machine object to something that implements > said interface. >=20 > It seemed a bit complicated for this particular problem, but I cannot > say it's overengineered. >=20 > More aspects of the configuration could be moved to the new interface > over time, for example compat properties. I remember Herv=E9 running into problems with interfaces and ppc -cpu ? (or -cpu host?), which does an object_class_foreach(), in the middle of which QOM interfaces tried registering new types, leading to a GLib assertion. Anthony never replied to that patch despite repeated pings, so the issue is likely still unresolved. http://patchwork.ozlabs.org/patch/241072/ (proposed workaround) http://patchwork.ozlabs.org/patch/241504/ (test case) http://patchwork.ozlabs.org/patch/241073/ (actual interface attempt) I've thus been avoiding interfaces. They are also kind of odd wrt memory management since even when we object_initialize() previously allocated memory, interfaces of that type are not part of the object size and are still dynamically allocated IIRC. That may well be fixable of course by allocating space for interfaces after the instance_size and bumping its copy in TypeImpl::instance_size accordingly or calculate it in my proposed type_get_instance_size(). http://patchwork.ozlabs.org/patch/269591/ http://patchwork.ozlabs.org/patch/269595/ (Which is BTW where I long wanted to introduce a static error_oom similar to the error_abort discussed in a different thread now.) Andreas --=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