lkml.org 
[lkml]   [2015]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Abuse of CONFIG_FOO's as feature selectors
    From
    Date
    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



    \
     
     \ /
      Last update: 2015-04-23 22:01    [W:2.454 / U:1.072 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site