From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48207) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnrR7-00044g-Qu for qemu-devel@nongnu.org; Tue, 03 Dec 2013 09:58:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VnrR2-0003I7-U6 for qemu-devel@nongnu.org; Tue, 03 Dec 2013 09:58:53 -0500 Message-ID: <529DF195.3090107@redhat.com> Date: Tue, 03 Dec 2013 15:58:29 +0100 From: Paolo Bonzini 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> <529DEC1A.2030306@suse.de> In-Reply-To: <529DEC1A.2030306@suse.de> 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: =?ISO-8859-1?Q?Andreas_F=E4rber?= 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?= Il 03/12/2013 15:35, Andreas F=E4rber ha scritto: > 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 v= l.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. >> >> Another solution would be to: >> >> (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. >> >> (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 th= ere. >> >> (3) for spapr, define the machine object to something that implements >> said interface. >> >> It seemed a bit complicated for this particular problem, but I cannot >> say it's overengineered. >> >> More aspects of the configuration could be moved to the new interface >> over time, for example compat properties. >=20 > 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. >=20 > 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) Well, let's fix it. Thanks for the test case. > They are also kind of odd wrt memory management since even when we > object_initialize() previously allocated memory, interfaces of that typ= e > 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/ No, that has changed since commit 33e95c6 (qom: Reimplement Interfaces, 2012-08-10). Paolo