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-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
