Re: ARM defconfig files

[Linus Torvalds <torvalds@linux-foundation.org>]

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