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: <alpine.LFD.2.00.1006031258350.8175@i5.linux-foundation.org>
Date:	Thu, 3 Jun 2010 13:05:22 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Daniel Walker <dwalker@...eaurora.org>
cc:	Russell King <rmk@....linux.org.uk>,
	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, Daniel Walker wrote:
> 
> If you did this for drivers, what about disabling a driver? If we used
> "select" wouldn't that force all the drivers on without allowing it to
> be unselected?

Isn't that the point? If you have a specific platform, you don't want to 
pick them, you want to get the particular config file for it as a starting 
point. That's the _only_ reason to have those insane 177 defconfig files - 
because you want a _particular_ one.

Once you have a particular one, you can always edit it with the regular 
configuration tools - including making tweaks by hand - as much as you 
want.

So the only point of the thing would always be to get a result config 
file, one that you can then edit to your hearts content. And get it from a 
human-readable and writable description file, so that it would make sense 
to check it in to the kernel repository.

Because right now, the current defconfig files DO NOT MAKE SENSE in the 
kernel repository. They are useless crud, and they hurt.

So what I do _not_ want is the current crazy "give people these totally 
unreadable and unwritable raw config files". I want that extra step in 
between: something that allows you to _generate_ those idiotic files, but 
generate them from a reasonable human-editable template.

And a Kconfig.xyz file _could_ be such a template. 

But anyway, I'm not actually all that excited about playing games with 
Kconfig files either. And I simply don't care. To me, a "git rm 
*defconfig" is perfectly acceptable. If you want to keep the current 
defconfig files, you can keep them on some random ARM site ("Here's a 
defconfig file for Nexus One").

So I'm actually perfectly fine with "no defconfig files at all, not even a 
template that can generate them". You can get the files from somewhere 
else where they don't hurt the kernel.

			Linus
--
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/