On Thu, 3 Jan 2002, Alan Cox wrote:
> > So you're saying the users should be completely lost any time they want
> > to use an upated kernel?
>
> Quite honestly if you want a user built "update" kernel it should probably
> work out the critical stuff (CPU, memory size limit, SMP) set a few things
> to safe values, and build all the driver modules.
If the previous config is saved automatically that could be used and do an
oldconfig as the autoconfig.
kbuild 2.5 has /lib/modules/`uname -r`/.config ?
the old idea of appending config.gz to the kernel image
/etc/defkernel.config
...
If this is for people doing updates I can't imagine anything better than
using the existing config as a base. Even if the config is a vendor config
and they are now building a non-vendor kernel.
That would help people from turning off things they (think they) don't
need but that their init scripts assume is there. Things you can't
autodetect.
The first step from vendor kernel to a custom one will mean that a few
options are no longer vaild, but that shouldn't be a problem for
oldconfig.
Or perhaps do both, get the old config as base, then autodetect the
hardware you can find. Any new options are set to on or off based on the
detected hardware. After that you let the user turn things on and off.
If the user tries to turn off something that you know he has in the box
give a big warning ("Are you sure you want to disable IDE? I can see that
you have both an IDE HD and CD-ROM. This behaviour is inconsistent with
logic." :)
All of this is of course for the "Aunt Tilly" mode only.
(make tillyconfig? :)
/Urban
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 07 2002 - 21:00:21 EST