Messages in this thread | | | Date | Wed, 22 Apr 2015 20:20:21 +0200 | From | Denys Vlasenko <> | Subject | Abuse of CONFIG_FOO's as feature selectors |
| |
Hi,
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.
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.
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?
| |