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]

Message-ID: <20100603181010.GA25779@flint.arm.linux.org.uk>
Date:	Thu, 3 Jun 2010 19:10:10 +0100
From:	Russell King <rmk@....linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Kevin Hilman <khilman@...prootsystems.com>,
	Daniel Walker <dwalker@...eaurora.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-arm-msm@...r.kernel.org
Subject: Re: ARM defconfig files

On Thu, Jun 03, 2010 at 07:48:18AM -0700, Linus Torvalds wrote:
> So I _think_ whatever "mach-xyz" file _should_ do something like
> 
> 	# Kconfig file for OMAP4ABCXYZ chip
> 
> 	.. set the particulars for this _particular_ chip,
> 	   ie select the particular drivers on this chip ..
> 
> 	include "chip-family-details" (ie maybe "base OMAP details")
> 
> 	include "architecture-family-details" (ie ARM Kconfig)
> 
> see? Not one flat file, and very much not something generated.

Umm...

> And I actually suspect we could do it with our current Kconfig file model. 
> IOW, in the arch/arm/Kconfig file, I think it should be doable to have 
> basically a
> 
> 	choice
> 		prompt "ARM platform"
> 
> 	config ARM_PLATFORM_OMAP
> 		bool PLATFORM_OMAP
> 
> 	config ARM_PLATFORM_MSM
> 		bool PLATFORM_MSM
> 	...
> 	endchoice

Umm.  I don't think you've actually looked at the Kconfig files if you're
writing this, because that's precisely what we already do.

arch/arm/Kconfig has a big choice statement in it to select the machine
class, and then it sources the individual arch/arm/*/Kconfig files,
which are themselves wrapped in a

if FOO

foo's options

endif

It's not one huge big "let's source everything and hope people ignore
options which don't apply to their platform" that you seem to be implying
we are doing.

The big problem with doing away with the defconfig files is more to do
with what happens _outside_ of arch/arm.

At one time, I was phasing IDE out, and didn't want to see the "IDE"
configuration options on platforms which either never had IDE support
or had had IDE support removed - unfortunately I was overruled by the
IDE/ATA developers and the conditionals we had went away.

That's just one instance, but consider when you're presented with
thousands of driver and filesystem configuration options as is the
case with modern kernels.  How do you find the few options you need
to get to a point that the kernel you've built is actually useful?

Anyway, I thought we were discussing _defconfig_ files, not Kconfig
files...

What we _could_ to is introduce a:

config STD_CONFIG
	bool "Enable me to generate a standard configuration for your platform"

and then have platforms conditionally select everything that's
appropriate for their use.  That provides a way to avoid the ages old
issue of select forcing options on, but the user still being presented
with the option and being told the only possible value for it is 'y'.

And yes, it _is_ necessary - because if you want to turn off something
on the platform - eg, you're not using MMC and MMC fails to build -
you can still end up with a working configuration at the end of the
day.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
--
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/