[lkml]   [1999]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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

    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

    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. |

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:52    [W:0.022 / U:86.044 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site