From: Paul Bolle <pebolle@tiscali.nl>
To: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Andreas Ruprecht <andreas.ruprecht@fau.de>,
Stefan Hengelein <stefan.hengelein@fau.de>,
linux-kernel@vger.kernel.org
Subject: Re: Abuse of CONFIG_FOO's as feature selectors
Date: Thu, 23 Apr 2015 21:28:03 +0200 [thread overview]
Message-ID: <1429817283.2927.35.camel@x220> (raw)
In-Reply-To: <5537E665.3010800@redhat.com>
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
prev parent reply other threads:[~2015-04-23 19:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-22 18:20 Abuse of CONFIG_FOO's as feature selectors Denys Vlasenko
2015-04-22 18:56 ` Andreas Ruprecht
2015-04-23 12:11 ` Stefan Hengelein
2015-04-23 19:28 ` Paul Bolle [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1429817283.2927.35.camel@x220 \
--to=pebolle@tiscali.nl \
--cc=andreas.ruprecht@fau.de \
--cc=dvlasenk@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stefan.hengelein@fau.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).