linux-kernel - Re: Abuse of CONFIG_FOO's as feature selectors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5537EEF6.7020502@fau.de>
Date:	Wed, 22 Apr 2015 20:56:54 +0200
From:	Andreas Ruprecht <andreas.ruprecht@....de>
To:	Denys Vlasenko <dvlasenk@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>
CC:	Stefan Hengelein <stefan.hengelein@....de>,
	Paul Bolle <pebolle@...cali.nl>
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/