> No, a _file_ /etc/kernel.conf is IMO a bad idea. Those who really need to know how a kernel
> was built usually have more than one kernel to boot, so this information must
> be stored _in_ the kernel image.
Actually, that's a very sweeping statement. For example, I rarely compile
kernels for more than one machine on my system, and I suspect there are a
lot of us in the same boat (there being more Linux users than developers ;).
When I get a new kernel, I want it compiled with exactly the same
configuration as the old one, except of course for new options.
I suspect that there are a lot of admins out there with only one system, or
who compile each kernel on the system where it will run. People with
multiple configurations who are somehow `offended' at the thought of a
global configuration can simply not create the file. ;)
Thus the configuration targets would search:
/etc/kernel.<arch>.conf
<current-source-tree>/arch/<arch>/defconfig
to find a default configuration if there is no .config. They would then
tell you where they found the default configuration.
If you used /etc/kernel.<arch>.conf, and if .config ended up different,
/etc/kernel.<arch>.conf would be updated accordingly by the kernel
configuration target, and the configuration targets would so state at the
end of configuration..
This way people with relatively simple configurations (i.e., one per
architecture, i.e. the average user) could use a global configuration that
wouldn't get wiped out each time. Developers could have all the separate
configurations they wanted without walking over the average admin for their
own personal convenience. They simply wouldn't create the
/etc/kernel.<arch>.conf files.
lilo