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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
