linux-kernel - Re: ARM defconfig files

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]

Date:	Thu, 03 Jun 2010 16:34:20 -0400 (EDT)
From:	Nicolas Pitre <nico@...xnic.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Russell King <rmk@....linux.org.uk>,
	Daniel Walker <dwalker@...eaurora.org>,
	Kevin Hilman <khilman@...prootsystems.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-arm-msm@...r.kernel.org
Subject: Re: ARM defconfig files

On Thu, 3 Jun 2010, Linus Torvalds wrote:

> 
> 
> On Thu, 3 Jun 2010, Russell King wrote:
> > 
> > I already covered that in my (ignored) email where I brought up a
> > "STD_CONFIG" config symbol, which could be disabled to turn off all
> > these additional "select"s.
> 
> I apparently haven't explained myself enough, because what you keep on 
> harping on is not something I consider acceptable.
> 
> STD_CONFIG is pointless. It's pointless because the solution to what 
> you call STD_CONFIG would be to just NOT USING the special Kconfig.xyz 
> file at all.

Linus, I think somehow you and Russell are talking past each other.

I must admit I don't exactly understand what your suggestion is all 
about.  But I however think that Russell's suggestion makes tons of 
sense.  Care to elaborate on what you dislike about it?

What is this Kconfig.xyz you're talking about?  How different is it 
from, say, arch/arm/mach-pxa/Kconfig?  If you look into that file, 
you'll find a bunch of select's which are fundamentally needed for the 
given targets to boot.  This file could be augmented with more 
conditional select's 
à la STD_CONFIG as Russell is advocating to actually provide defaults 
for the drivers that those targets should have by default.

Nicolas
> So when I suggest special Kconfig files, they are meant to just generate 
> the templates - ie they'd _generate_ what is currently the defconfig 
> files. You wouldn't _have_ to use them at all.

Sure.  a standard "make config" would still produce that .defconfig as 
usual.  Only that you'd have to turn STD_CONFIG off to be offered the 
choice of enabling/disabling those drivers which are enabled by default 
otherwise, just like the "make foo_defconfig" is doing now.

Nicolas