Looking for Better Ways to Configure Kernels.

[Martin McCormick]

	I am building a new 2.6 kernel and have decided that it is
time to look for a different method.  What I always did in the past is
to download the new kernel I wanted, unpack it in /usr/src/linux and
then do the following:

make mrproper #That cleans everything up and lets you start from scratch.
make config #That starts the question and answer script which prompts
you all the way through the process.

	There are more and more questions as the kernel grows up.  I
counted 493 on my most recent attempt and I still realized that I
forgot something by the time I got to the end.

	I access Linux via an old P.C. running DOS, a screen reader
and kermit software.  In the past, I captured the session and then ran
those data through a filter I wrote in C to convert that session in to
a kermit script that one can feed back in to the build process.

	The advantage is that if you want to keep everything up to the
420TH question, you just let the script run and make sure it runs out
of anything to do at that point.  You then start a new log and
manually answer the different questions until you see it merge back in
to the same set of questions it was answering before.  At that point,
you can merge your new script with your old one and go on.

	There is an option to use the old configuration as in  make
-oldconfig.  It certainly remembers your last session, but it just
lets you make another kernel like the last one which may not be what
you wanted.

	Is there a way besides kermit or expect scripts to safely edit
the configuration and still preserve all those tedious lines of
question and answer that don't change from one build to the next such
as all those code pages for various international file name support,
etc?

	I expect to have to answer all the questions the first time
through because those change drastically from one kernel to the next,
but it certainly would be nice to have a way to only answer those
lines of questions caused by changing some particular part of the
kernel rather than the whole works every time.

	A really neat thing would be if you could feed the output of
dmesg in to the process to answer all the hardware support questions.

I have a Linux system at work and one at home and, after a year or
two, it gets hard to remember whether this or that system is the one
with the PIX3 hard drive controller, etc.

	For those who haven't ever configured a Linux kernel, it is
more tedious than difficult.  The one thing you do need to have handy
is a list of all your hardware and network cards, preferably the
output of dmesg if you have booted a generic kernel.  You don't want
to compile anything you don't support since at best, it will make your
kernel bigger than it needs to be and at worst, it may make it fail
because it is looking for something that isn't there.

	Another reason I like to automate much of the kernel
rebuild process is that it gives you something to look at later if you
are not sure how you originally answered some of the more obscure
questions.  Believe me, some of them get pretty strange and one isn't
sure whether or not they apply or not.  A scripted rebuild lets you
quickly answer the question, "What would happen if I tried this or
that?"  You will know that you kept everything else the way it was and
only changed the part you wanted to change.

	Any suggestions are appreciated and I will certainly share any
thing I find out about that makes this process a little more
efficient.

Martin McCormick WB5AGZ  Stillwater, OK 
OSU Information Technology Division Network Operations Group