Messages in this thread | | | Date | Sun, 4 Jul 1999 23:28:44 +0100 (GMT) | From | Riley Williams <> | Subject | Kernel 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/
| |