All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>, qemu-devel@nongnu.org
Cc: Eduardo Habkost <ehabkost@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
	qemu-ppc@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <rth@twiddle.net>,
	Artyom Tarasenko <atar4qemu@gmail.com>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [PATCH v3 5/7] hw/ppc: Implement fw_cfg_arch_key_name()
Date: Mon, 29 Apr 2019 18:01:44 +0200	[thread overview]
Message-ID: <7064b823-3016-142f-5b1b-28a46fd6272a@redhat.com> (raw)
In-Reply-To: <ccbc2340-1f33-000f-0f7e-051b67337a85@redhat.com>

Hi Laszlo,

On 4/23/19 9:02 PM, Laszlo Ersek wrote:
> On 04/22/19 21:50, Philippe Mathieu-Daudé wrote:
>> Implement fw_cfg_arch_key_name(), which returns the name of a
>> ppc-specific key.
>>
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>> ---
>>  hw/ppc/Makefile.objs |  2 +-
>>  hw/ppc/fw_cfg.c      | 45 ++++++++++++++++++++++++++++++++++++++++++++
>>  2 files changed, 46 insertions(+), 1 deletion(-)
>>  create mode 100644 hw/ppc/fw_cfg.c
>>
>> diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
>> index 1111b218a04..ae940981553 100644
>> --- a/hw/ppc/Makefile.objs
>> +++ b/hw/ppc/Makefile.objs
>> @@ -1,5 +1,5 @@
>>  # shared objects
>> -obj-y += ppc.o ppc_booke.o fdt.o
>> +obj-y += ppc.o ppc_booke.o fdt.o fw_cfg.o
>>  # IBM pSeries (sPAPR)
>>  obj-$(CONFIG_PSERIES) += spapr.o spapr_caps.o spapr_vio.o spapr_events.o
>>  obj-$(CONFIG_PSERIES) += spapr_hcall.o spapr_iommu.o spapr_rtas.o
>> diff --git a/hw/ppc/fw_cfg.c b/hw/ppc/fw_cfg.c
>> new file mode 100644
>> index 00000000000..a88b5c4bde2
>> --- /dev/null
>> +++ b/hw/ppc/fw_cfg.c
>> @@ -0,0 +1,45 @@
>> +/*
>> + * fw_cfg helpers (PPC specific)
>> + *
>> + * Copyright (c) 2019 Red Hat, Inc.
>> + *
>> + * Author:
>> + *   Philippe Mathieu-Daudé <philmd@redhat.com>
>> + *
>> + * SPDX-License-Identifier: GPL-2.0-or-later
>> + *
>> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
>> + * See the COPYING file in the top-level directory.
>> + */
>> +
>> +#include "qemu/osdep.h"
>> +#include "hw/ppc/ppc.h"
>> +#include "hw/nvram/fw_cfg.h"
>> +
>> +const char *fw_cfg_arch_key_name(uint16_t key)
>> +{
>> +    static const struct {
>> +        uint16_t key;
>> +        const char *name;
>> +    } fw_cfg_arch_wellknown_keys[] = {
>> +        {FW_CFG_PPC_WIDTH, "width"},
>> +        {FW_CFG_PPC_HEIGHT, "height"},
>> +        {FW_CFG_PPC_DEPTH, "depth"},
>> +        {FW_CFG_PPC_TBFREQ, "tbfreq"},
>> +        {FW_CFG_PPC_CLOCKFREQ, "clockfreq"},
>> +        {FW_CFG_PPC_IS_KVM, "is_kvm"},
>> +        {FW_CFG_PPC_KVM_HC, "kvm_hc"},
>> +        {FW_CFG_PPC_KVM_PID, "pid"},
>> +        {FW_CFG_PPC_NVRAM_ADDR, "nvram_addr"},
>> +        {FW_CFG_PPC_BUSFREQ, "busfreq"},
>> +        {FW_CFG_PPC_NVRAM_FLAT, "nvram_flat"},
>> +        {FW_CFG_PPC_VIACONFIG, "viaconfig"},
>> +    };
>> +
>> +    for (size_t i = 0; i < ARRAY_SIZE(fw_cfg_arch_wellknown_keys); i++) {
>> +        if (fw_cfg_arch_wellknown_keys[i].key == key) {
>> +            return fw_cfg_arch_wellknown_keys[i].name;
>> +        }
>> +    }
>> +    return NULL;
>> +}
>>
> 
> (1) Have you considered extracting the struct type, and the linear
> search, to code that's shared between the arches?
> 
> It might suffice to make only the "fw_cfg_arch_wellknown_keys" array
> target-specific.

Yes, I tried different ways:

1/ Declare as extern

If we declare the array as 'extern const', we can no more use the
ARRAY_SIZE() macro, so we have to use an 'extern const size_t' too.
(No need to use a getter() since the array is *const*).

I personally try to avoid extern variables when possible, I find them
bug prone.

2/ Add a macro in the header, use it in each source

The macro is ugly to read, the result looked worse to me.

3/ I don't expect new keys to be added often, and adding them will be
trivial 1-line patch each key.

I might be unaware of better ways to deduplicate this, so if you have
suggestions I'm happy to learn :)

> (It's not complex code so I don't mind if you opt for the code duplication.)
> 
> (2) PPC highlights my question#2 from under "v3 3/7". Namely, we
> extracted the x86 constants into "hw/i386/fw_cfg.h". But the PPC
> constants already exist in "include/hw/ppc/ppc.h". (My point being the
> difference in the "include/" pathname prefix.) Should we be consistent?

I'd like to be consistent :)

So far only machines set fw_cfg keys.

I don't see arch-specific devices accessing arch-specific fw_cfg keys,
so we might move arch-specific key definitions in hw/$ARCH/fw_cfg.h (not
include/hw/$ARCH/fw_cfg.h).

> If you decide to stick with this variant:
> 
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>

Thanks!

> 
> Thanks
> Laszlo
> 

WARNING: multiple messages have this Message-ID (diff)
From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>, qemu-devel@nongnu.org
Cc: Eduardo Habkost <ehabkost@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
	qemu-ppc@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	David Gibson <david@gibson.dropbear.id.au>,
	Artyom Tarasenko <atar4qemu@gmail.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v3 5/7] hw/ppc: Implement fw_cfg_arch_key_name()
Date: Mon, 29 Apr 2019 18:01:44 +0200	[thread overview]
Message-ID: <7064b823-3016-142f-5b1b-28a46fd6272a@redhat.com> (raw)
Message-ID: <20190429160144.-zrrzIMVMumzrauIxGDt68FJayZbErAFRdyEKroqi3A@z> (raw)
In-Reply-To: <ccbc2340-1f33-000f-0f7e-051b67337a85@redhat.com>

Hi Laszlo,

On 4/23/19 9:02 PM, Laszlo Ersek wrote:
> On 04/22/19 21:50, Philippe Mathieu-Daudé wrote:
>> Implement fw_cfg_arch_key_name(), which returns the name of a
>> ppc-specific key.
>>
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>> ---
>>  hw/ppc/Makefile.objs |  2 +-
>>  hw/ppc/fw_cfg.c      | 45 ++++++++++++++++++++++++++++++++++++++++++++
>>  2 files changed, 46 insertions(+), 1 deletion(-)
>>  create mode 100644 hw/ppc/fw_cfg.c
>>
>> diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
>> index 1111b218a04..ae940981553 100644
>> --- a/hw/ppc/Makefile.objs
>> +++ b/hw/ppc/Makefile.objs
>> @@ -1,5 +1,5 @@
>>  # shared objects
>> -obj-y += ppc.o ppc_booke.o fdt.o
>> +obj-y += ppc.o ppc_booke.o fdt.o fw_cfg.o
>>  # IBM pSeries (sPAPR)
>>  obj-$(CONFIG_PSERIES) += spapr.o spapr_caps.o spapr_vio.o spapr_events.o
>>  obj-$(CONFIG_PSERIES) += spapr_hcall.o spapr_iommu.o spapr_rtas.o
>> diff --git a/hw/ppc/fw_cfg.c b/hw/ppc/fw_cfg.c
>> new file mode 100644
>> index 00000000000..a88b5c4bde2
>> --- /dev/null
>> +++ b/hw/ppc/fw_cfg.c
>> @@ -0,0 +1,45 @@
>> +/*
>> + * fw_cfg helpers (PPC specific)
>> + *
>> + * Copyright (c) 2019 Red Hat, Inc.
>> + *
>> + * Author:
>> + *   Philippe Mathieu-Daudé <philmd@redhat.com>
>> + *
>> + * SPDX-License-Identifier: GPL-2.0-or-later
>> + *
>> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
>> + * See the COPYING file in the top-level directory.
>> + */
>> +
>> +#include "qemu/osdep.h"
>> +#include "hw/ppc/ppc.h"
>> +#include "hw/nvram/fw_cfg.h"
>> +
>> +const char *fw_cfg_arch_key_name(uint16_t key)
>> +{
>> +    static const struct {
>> +        uint16_t key;
>> +        const char *name;
>> +    } fw_cfg_arch_wellknown_keys[] = {
>> +        {FW_CFG_PPC_WIDTH, "width"},
>> +        {FW_CFG_PPC_HEIGHT, "height"},
>> +        {FW_CFG_PPC_DEPTH, "depth"},
>> +        {FW_CFG_PPC_TBFREQ, "tbfreq"},
>> +        {FW_CFG_PPC_CLOCKFREQ, "clockfreq"},
>> +        {FW_CFG_PPC_IS_KVM, "is_kvm"},
>> +        {FW_CFG_PPC_KVM_HC, "kvm_hc"},
>> +        {FW_CFG_PPC_KVM_PID, "pid"},
>> +        {FW_CFG_PPC_NVRAM_ADDR, "nvram_addr"},
>> +        {FW_CFG_PPC_BUSFREQ, "busfreq"},
>> +        {FW_CFG_PPC_NVRAM_FLAT, "nvram_flat"},
>> +        {FW_CFG_PPC_VIACONFIG, "viaconfig"},
>> +    };
>> +
>> +    for (size_t i = 0; i < ARRAY_SIZE(fw_cfg_arch_wellknown_keys); i++) {
>> +        if (fw_cfg_arch_wellknown_keys[i].key == key) {
>> +            return fw_cfg_arch_wellknown_keys[i].name;
>> +        }
>> +    }
>> +    return NULL;
>> +}
>>
> 
> (1) Have you considered extracting the struct type, and the linear
> search, to code that's shared between the arches?
> 
> It might suffice to make only the "fw_cfg_arch_wellknown_keys" array
> target-specific.

Yes, I tried different ways:

1/ Declare as extern

If we declare the array as 'extern const', we can no more use the
ARRAY_SIZE() macro, so we have to use an 'extern const size_t' too.
(No need to use a getter() since the array is *const*).

I personally try to avoid extern variables when possible, I find them
bug prone.

2/ Add a macro in the header, use it in each source

The macro is ugly to read, the result looked worse to me.

3/ I don't expect new keys to be added often, and adding them will be
trivial 1-line patch each key.

I might be unaware of better ways to deduplicate this, so if you have
suggestions I'm happy to learn :)

> (It's not complex code so I don't mind if you opt for the code duplication.)
> 
> (2) PPC highlights my question#2 from under "v3 3/7". Namely, we
> extracted the x86 constants into "hw/i386/fw_cfg.h". But the PPC
> constants already exist in "include/hw/ppc/ppc.h". (My point being the
> difference in the "include/" pathname prefix.) Should we be consistent?

I'd like to be consistent :)

So far only machines set fw_cfg keys.

I don't see arch-specific devices accessing arch-specific fw_cfg keys,
so we might move arch-specific key definitions in hw/$ARCH/fw_cfg.h (not
include/hw/$ARCH/fw_cfg.h).

> If you decide to stick with this variant:
> 
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>

Thanks!

> 
> Thanks
> Laszlo
> 


  reply	other threads:[~2019-04-29 16:01 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-22 19:50 [Qemu-devel] [PATCH v3 0/7] fw_cfg: Improve tracing Philippe Mathieu-Daudé
2019-04-22 19:50 ` Philippe Mathieu-Daudé
2019-04-22 19:50 ` [Qemu-devel] [PATCH v3 1/7] hw/nvram/fw_cfg: Add trace events Philippe Mathieu-Daudé
2019-04-22 19:50   ` Philippe Mathieu-Daudé
2019-04-22 19:50 ` [Qemu-devel] [PATCH v3 2/7] hw/nvram/fw_cfg: Add fw_cfg_arch_key_name() Philippe Mathieu-Daudé
2019-04-22 19:50   ` Philippe Mathieu-Daudé
2019-04-23 18:32   ` Laszlo Ersek
2019-04-23 18:32     ` Laszlo Ersek
2019-04-22 19:50 ` [Qemu-devel] [PATCH v3 3/7] hw/i386: Extract fw_cfg definitions to local "fw_cfg.h" Philippe Mathieu-Daudé
2019-04-22 19:50   ` Philippe Mathieu-Daudé
2019-04-23 18:38   ` Laszlo Ersek
2019-04-23 18:38     ` Laszlo Ersek
2019-04-29 15:41     ` Philippe Mathieu-Daudé
2019-04-29 15:41       ` Philippe Mathieu-Daudé
2019-04-22 19:50 ` [Qemu-devel] [PATCH v3 4/7] hw/i386: Implement fw_cfg_arch_key_name() Philippe Mathieu-Daudé
2019-04-22 19:50   ` Philippe Mathieu-Daudé
2019-04-23 18:40   ` Laszlo Ersek
2019-04-23 18:40     ` Laszlo Ersek
2019-04-22 19:50 ` [Qemu-devel] [PATCH v3 5/7] hw/ppc: " Philippe Mathieu-Daudé
2019-04-22 19:50   ` Philippe Mathieu-Daudé
2019-04-23  1:20   ` David Gibson
2019-04-23  1:20     ` David Gibson
2019-04-23  7:31     ` Philippe Mathieu-Daudé
2019-04-23  7:31       ` Philippe Mathieu-Daudé
2019-04-23 19:02   ` Laszlo Ersek
2019-04-23 19:02     ` Laszlo Ersek
2019-04-29 16:01     ` Philippe Mathieu-Daudé [this message]
2019-04-29 16:01       ` Philippe Mathieu-Daudé
2019-04-30  9:41       ` Laszlo Ersek
2019-04-30  9:41         ` Laszlo Ersek
2019-04-30  9:58         ` Philippe Mathieu-Daudé
2019-04-30  9:58           ` Philippe Mathieu-Daudé
2019-04-22 19:50 ` [Qemu-devel] [PATCH v3 6/7] hw/sparc: " Philippe Mathieu-Daudé
2019-04-22 19:50   ` Philippe Mathieu-Daudé
2019-04-23 19:05   ` Laszlo Ersek
2019-04-23 19:05     ` Laszlo Ersek
2019-04-22 19:50 ` [Qemu-devel] [PATCH v3 7/7] hw/sparc64: " Philippe Mathieu-Daudé
2019-04-22 19:50   ` Philippe Mathieu-Daudé
2019-04-23 19:06   ` Laszlo Ersek
2019-04-23 19:06     ` Laszlo Ersek
2019-05-22 14:24 ` [Qemu-devel] [PATCH v3 0/7] fw_cfg: Improve tracing Philippe Mathieu-Daudé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7064b823-3016-142f-5b1b-28a46fd6272a@redhat.com \
    --to=philmd@redhat.com \
    --cc=atar4qemu@gmail.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=ehabkost@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=lersek@redhat.com \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.