Re: Abuse of CONFIG_FOO's as feature selectors

[Paul Bolle]

On Wed, 2015-04-22 at 20:20 +0200, Denys Vlasenko wrote:
> Kernel has a growing number of CONFIG items which are not
> user-selectable features of their particular kernel builds,
> but simply booleans controlled by other CONFIGs.
> Example:
> 
> config X86
>         def_bool y
>         select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI
>         select ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
>         select ARCH_HAS_FAST_MULTIPLIER
>         select ARCH_HAS_GCOV_PROFILE_ALL
>         select ARCH_MIGHT_HAVE_PC_PARPORT
>         select ARCH_MIGHT_HAVE_PC_SERIO
>         select HAVE_AOUT if X86_32
>         select HAVE_UNSTABLE_SCHED_CLOCK
>         select ARCH_SUPPORTS_NUMA_BALANCING if X86_64
>         select ARCH_SUPPORTS_INT128 if X86_64
>         select HAVE_IDE
>         select HAVE_OPROFILE
>         ...
> 
> I see how this practice originated: "select" statement
> was initially added so that if feature X requires feature Y,
> this can be enforced, but it was easy to use it to define
> other booleans.
> 
> I have a feeling that in retrospect, it was a mistake.
> 
> It clutters .config with information which has nothing to do
> with user's choice.

No, those selects fill the .config with values as a direct consequence
of the choices made by the person doing the configuration. You might
just as well consider those values things that the user wanted to have
too.

> More importantly, now when you read some code, you don't know
> whether a CONFIG_FOO you look at is user's configuration choice
> or something else.

So what?

> Now there are hundreds, maybe even thousands of these non-config
> CONFIGs everywhere.
>
> The same effect can be achieved, with marginally more typing,
> with usual C defines in some header file:
> 
> #ifdef CONFIG_X86
> # define ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
> # define ARCH_HAS_FAST_MULTIPLIER
> # define ARCH_HAS_GCOV_PROFILE_ALL
> # define ARCH_MIGHT_HAVE_PC_PARPORT
> # define ARCH_MIGHT_HAVE_PC_SERIO
> ...
> 
> Maybe we should stop doing the former and use the latter method?

And lose the sanity checks that the kconfig tools provide? And the
benefit of a having a single .config file showing the configuration the
build will (or did) use?

Anyhow, -ENOPATCH. Because I actually suspect that this scheme will
complicate the tree quite a bit. Do send in patches showing how this
scheme allows to drop a few Kconfig symbols. That makes it much easier
to evaluate the pros and cons of your idea.

Thanks,


Paul Bolle

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/