Re: [PATCH 1/4] hw/sh4/Kconfig: Rename CONFIG_SH4 -> CONFIG_SH4_DEVICES

["Philippe Mathieu-Daudé" <f4bug@amsat.org>]

On 2/8/21 9:22 PM, Peter Maydell wrote:
> On Mon, 8 Feb 2021 at 20:04, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>>
>> We want to be able to use the 'SH4' config for architecture
>> specific features. As CONFIG_SH4 is only used to select
>> peripherals, rename it CONFIG_SH4_DEVICES.
>>
>> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
>> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>> ---
>>  hw/block/meson.build | 2 +-
>>  hw/char/meson.build  | 2 +-
>>  hw/intc/meson.build  | 2 +-
>>  hw/sh4/Kconfig       | 6 +++---
>>  hw/timer/meson.build | 2 +-
>>  5 files changed, 7 insertions(+), 7 deletions(-)
> 
> We could if we wished be more fine-grained about this, eg by
> adding new CONFIG options for each device:
>  CONFIG_TC58128
>  CONFIG_SH_SERIAL
>  CONFIG_SH_INTC
>  CONFIG_SH_TIMER
>  CONFIG_SH_PCI
> 
> and then in hw/sh4/Kconfig
>  * config SH7750:
>    add 'select SH_SERIAL', 'select SH_INTC', 'select SH_TIMER'
>  * config R2D:
>    add 'select SH7750' (it's a pre-existing bug that it doesn't, since
>    r2d.c has a call to sh7750_init(). Harmless at the moment because
>    nothing actually uses CONFIG_SH7750 -- hw/sh4/meson.build always
>    compiles sh7750.c and sh7750_regnames.c unconditionally...)
>    add 'select SH_PCI' (and make hw/sh4/meson.build build sh_pci.c
>    only if it is set...)
>  * config SHIX
>    add 'select TC58128'

OK.

> Do we have a general preference for how fine-grained we go with the
> Kconfig switches ? Looking at the arm code, in some cases we have
> a CONFIG_ for the SoC that uses 'select' to turn on a separate
> CONFIG_ for each device (the STM32 SoCs are done this way), and
> in some cases we just have the meson.build use the SoC's CONFIG_*
> to control whether we compile its devices (the Xilinx and Exynos4
> SoCs are done this way). When reviewing new code it would be helpful
> to know whether to suggest doing it one way or the other :-)

My view is:

- Use fine granularity with shared/reusable models, so if someone
  wants to build a QEMU for a single machine, it is possible (using
  --without-default-devices and a specific target config.mak).
  Example: STM32F205_SOC and STM32F405_SOC

- For some (family of) SoC, a single switch is acceptable. In
  particular when all models are implemented in the same source file.
  Example: ASPEED_SOC

- Do not look at hw/i386/Kconfig

I have an old branch where I was generating a .dot of the Kconfig tree
for easier visualization, fine granularity was helpful. I'll try to
update it.

Regards,

Phil.