lkml.org 
[lkml]   [1999]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectKernel autosetup script
Hi there.

There's been enough aggro regarding an autocompile script to last a
lifetime, but nobody seems to have addressed the real need, which
IMHO is a script that deals with the full process, starting with
"I've extracted the kernel tarball into this directory" and finishing
with "Good, I'm now using that kernel" - what I refer to as an
autosetup script.

Here's how I'd like to see any autosetup script working:

1. Ask the user whether we are compiling for the system we are
running on, or a different system.

2. If the answer to (1) is the current system, probe to see what
hardware currently exists, and create a DEFAULT setup to match
it. This at least assures that the user has to do the minimum
feasible when configuring their system, although it will not
guarantee a perfect setup.

A few things that should be possible to set up in this step are
processor family, bus types, bus bug workarounds, anything with
an entry in /proc/pci or /proc/mca (if the latter exists, I've
never run Linux on an mca bus system), any file systems listed
in /proc/filesystems, and similar information that's readily
available.

One thing to note is that this must NOT be the only config step
as some hardware just won't appear in the current system for no
better reason than that the current kernel doesn't support it.
One example of that is my parallel port ZipDrive, for which no
indication of its existence appears until the relevant driver
is loaded. It is for this reason that I believe this stage
should produce the DEFAULT configuration, not the CURRENT one,
ie, arch/*/defconfig rather than .config if that helps.
3. Ask the user which style of configuration script to use, only
offering xconfig if X is currently running, then run whichever
one they select.

4. Perform the "make dep clean" steps as required.

5. If modules are configured in, perform the "make modules" and
"make modules_install" steps.

6. Perform the "make zImage" step, and determine the result status.
If the result status was "failed due to compilation error", such
as one of the many typos that have appeared in recent 2.3 series
kernels, abort at this stage.

7. If the result status from step (6) was "failed due to kernel size
being too large", and ONLY if that was the result status, perform
the "make bzImage" step. This will whizz straight through most of
the kernel files as the selection of "zImage" or "bzImage" only
affects a small number of files, all of which are recompiled on
EVERY compile run.

The resulting script thus guarantees not only to configure the kernel,
but also to compile the kernel if it is actually possible for it to do
so.

Best wishes from Riley.

+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:52    [from the cache]
©2003-2011 Jasper Spaans