From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57000) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnqE9-0004ap-IO for qemu-devel@nongnu.org; Tue, 03 Dec 2013 08:41:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VnqE3-0001iG-7w for qemu-devel@nongnu.org; Tue, 03 Dec 2013 08:41:25 -0500 Message-ID: <529DDF7A.5020106@suse.de> Date: Tue, 03 Dec 2013 14:41:14 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1385364460-24332-1-git-send-email-aik@ozlabs.ru> <1385364460-24332-3-git-send-email-aik@ozlabs.ru> <529429AA.1000403@ozlabs.ru> <529D5570.8060205@ozlabs.ru> In-Reply-To: <529D5570.8060205@ozlabs.ru> Content-Type: text/plain; charset=UTF-8 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: Alexey Kardashevskiy , qemu-devel@nongnu.org Cc: Paolo Bonzini , qemu-ppc@nongnu.org Am 03.12.2013 04:52, schrieb Alexey Kardashevskiy: > On 11/26/2013 03:55 PM, Alexey Kardashevskiy wrote: >> Hi! >> >> btw there is a problem with this patch - it does not compile for >> "linux-user" as there is no current-machine global variable defined in= vl.c >> which is not compiled for linux-user. >> >> How to solve this problem correctly? >> >> >> On 11/25/2013 06:27 PM, Alexey Kardashevskiy wrote: >>> QEMU supports firmware names for all devices in the QEMU tree but >>> sometime the exact format differs from what sPAPR platform uses. >>> >>> This introduces a callback to let a machine fix device tree path name= s. >>> >>> Signed-off-by: Alexey Kardashevskiy >>> --- >>> hw/core/qdev.c | 15 ++++++++++++++- >>> include/hw/boards.h | 1 + >>> 2 files changed, 15 insertions(+), 1 deletion(-) >>> >>> diff --git a/hw/core/qdev.c b/hw/core/qdev.c >>> index e374a93..7347483 100644 >>> --- a/hw/core/qdev.c >>> +++ b/hw/core/qdev.c >>> @@ -26,6 +26,7 @@ >>> this API directly. */ >>> =20 >>> #include "hw/qdev.h" >>> +#include "hw/boards.h" >>> #include "sysemu/sysemu.h" >>> #include "qapi/error.h" >>> #include "qapi/qmp/qerror.h" >>> @@ -497,6 +498,15 @@ static char *bus_get_fw_dev_path(BusState *bus, = DeviceState *dev) >>> return NULL; >>> } >>> =20 >>> +static char *machine_get_fw_dev_path(BusState *bus, DeviceState *dev= ) >>> +{ >>> + if (current_machine->get_fw_dev_path) { >>> + return current_machine->get_fw_dev_path(bus, dev); >>> + } >>> + >>> + return NULL; >>> +} >>> + >=20 >=20 > Anyone, please? >=20 > The only easy fix for this I can think of would be this: >=20 > extern QEMUMachine *current_machine __attribute__((weak)); >=20 >=20 > But I suspect this is disgusting? :) Kind of. ;) It's introducing one concept in ppc code that's different from the rest of the code. And it has nothing to do with core device code, so please not in qdev.c. Better place this function close to where the current_machine variable actually lives (vl.c?) and add a stub function to stubs/ if needed. I don't see how a firmware device path might be relevant for linux-user though - so since the CPU will be the only device in linux-user, you might as well use an old-fashioned #ifdef around its usage (assuming that's reasonably contained) and just place the function where it makes the most sense for softmmus. Regards, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg