Messages in this thread | | | Date | Wed, 22 Apr 2015 20:56:54 +0200 | From | Andreas Ruprecht <> | Subject | Re: Abuse of CONFIG_FOO's as feature selectors |
| |
Hi,
On 22.04.2015 20:20, Denys Vlasenko wrote: > 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: > > 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.
Well, there seems to be at least some convention with regards to the name of those options: They all start with (ARCH_)HAS/HAVE/MIGHT_HAVE and so forth.
> > 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?
Problem is, most of these options which are not selectable by the user operate as something like a "bridge" inside Kconfig itself. For example, an architecture can specify that it has some specific feature upon which a driver might depend. So, the architecture Kconfig file can set the option, the driver can *depend* on it, allowing the driver only to be built on the right architectures.
Transferring everything into a header (quite like include/config/auto.conf works) would hence break the whole point of the "bridge" rationale behind it, as only the code (and not Kconfig) would be able to see this information.
But I generally agree, the distinction between configuration options selectable by the user, options only present to model dependencies inside the guts of Kconfig and other things (like CONFIG_AS_AVX2, which is only passed as a compiler parameter from a Makefile, yuck) is not clear at all and can be quite confusing.
Regards,
Andreas
P.S.: I've CCed some folks who might want to add their thoughts.
| |