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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ