The Linux kernel is a many-tentacled beast. Many groups of people work on different pieces of it, and some parts of the code are a patchwork of ideas meeting different design goals. Overall, however, the kernel code is clean and uniform, and those interested in exploring its innards should have little trouble doing so. However, because of the great amount of development going on with the kernel, new releases are made very rapidlysometimes daily! The chief reason for this is that nearly all device drivers are contained within the kernel code, and every time someone updates a driver, a new release is necessary. Even though almost all device drivers are loadable modules these days, they are still typically shipped together with the kernel as one big package.
Currently, Linus Torvalds maintains the "official" kernel release. Although the GPL allows anyone to modify and rerelease the kernel under the same copyright, Linus's maintenance of an "official" kernel is a helpful convention that keeps version numbers uniform and allows everyone to be on equal footing when talking about kernel revisions. In order for a bug fix or new feature to be included in the kernel, all one must do is send it to Linus (or whoever is in charge for the kernel series in question Linus himself always maintains the most current kernel), who will usually incorporate the change as long as it doesn't break anything. Linus also makes use of so-called lieutenants, very experienced kernel developers, who take care of particular subsystems.
Kernel version numbers follow the convention
major is the major version number, which rarely changes; minor is the minor version number, which indicates the current "strain" of the kernel release; and patchlevel is the number of the patch to the current kernel version. Some examples of kernel versions are 2.4.4 (patch level 4 of kernel Version 2.4), and 18.104.22.168 (subversion 4 of patch level 11 of kernel Version 2.6).
If you are interested in how the existing kernel versions have evolved, check out http://www.kernel.org.
On your system, the kernel sources most probably live in /usr/src/linux (unless you use the Debian distribution, where you can find the kernel sources in /usr/src/kernel-source-versionsnumber). If you are going to rebuild your kernel only from the current sources, you don't need to obtain any files or apply any patches (assuming you installed the kernel sources when you installed your system). If you wish to upgrade your kernel to a new version, you need to follow the instructions in the following section.
18.1.1. Obtaining Kernel Sources
The official kernel is released as a gzipped tar file, containing the sources along with a series of patch filesone per patch level. The tar file contains the source for the unpatched revision; for example, there is a tar file containing the sources for kernel Version 2.6.0 with no patches applied. Each subsequent patch level is released as a patch file (produced using diff), which can be applied using the patch program. In "Patching Files" in Chapter 21, we describe the use of patch in detail.
Let's say you're upgrading to kernel Version 2.6, patch level 4. You'll need the sources for 2.6 (the file might be named v2.6.0.tar.gz) and the patches for patch levels 1 through 4. These files would be named patch1, patch2, and so forth. (You need all the patch files up to the version to which you're upgrading. Usually, these patch files are rather small, and are gzipped on the archive sites.) All these files can be found in the kernel directory of the Linux FTP archive sites; for example, on ftp://ftp.kernel.org, the directory containing the 2.6 sources and patches is /pub/linux/kernel/v2.6. You will find the kernel sources here as tar archives, compressed with both gzip and bzip2.
If you are already at some patch level of the kernel (such as 2.6 patch level 2) and want to upgrade to a newer patch level, you can simply apply the patches from the version you have up to the version to which you'd like to upgrade. If you're upgrading from, say, 2.6 patch level 2 to 2.6 patch level 4, you need the patch files for 2.6.3 and 2.6.4.
22.214.171.124. Unpacking the sources
First, unpack the source tar file from /usr/src using commands such as:
rutabaga# cd /usr/src rutabaga# mv linux linux.old rutabaga# tar xzf v2.6.0.tar.gz
This saves your old kernel source tree as /usr/src/linux.old and creates /usr/src/linux containing the new sources. Note that the tar file containing the sources includes the linux subdirectory.
You should keep your current kernel sources in the directory /usr/src/linux because there are two symbolic links--/usr/include/linux and /usr/include/asm--that point into the current kernel source tree to provide certain header files when compiling programs. (If you are planning on doing any software development, you should always have your kernel sources available so that programs using these include files can be compiled.) If you want to keep several kernel source trees around, be sure that /usr/src/linux points to the most recent one.
126.96.36.199. Applying patches
If you are applying any patch files, use the patch program. Let's say that you have the files patch1.gz through patch4.gz, which are gzipped. These patches should be applied from the kernel sources main directory. That doesn't mean the patch files themselves should be located there, but rather that patch should be executed from, for example, /usr/src/linux. For each patch file, use the command:
gunzip -c patchfile | patch -p1
from /usr/src. The -p1 option tells patch it shouldn't strip any part of the filenames contained within the patch file except for the first one.
You must apply each patch in numerical order by patch level. This is very important. Note that using a wildcard such as patch* will not work because the * wildcard uses ASCII order, not numeric order. (Otherwise, if you are applying a larger number of patches, patch1 might be followed by patch10 and patch11, as opposed to patch2 and patch3.) It is best to run the previous command for each patch file in succession, by hand. This way you can ensure you're doing things in the right order.
You shouldn't encounter problems when patching your source tree in this way unless you try to apply patches out of order or apply a patch more than once. Check the patch manual page if you do encounter trouble. If all else fails, remove the new kernel source tree and start over from the original tar file.
To double-check that the patches were applied successfully, use the commands:
find /usr/src/linux -follow -name "*.rej" -print find /usr/src/linux -follow -name "*#" -print
This lists any files that are "rejected" portions of the patch process. If any such files exist, they contain sections of the patch file that could not be applied for some reason. Look into these, and if there's any doubt, start over from scratch. You cannot expect your kernel to compile or work correctly unless the patch process completes successfully and without rejections.
A handy script for patching the kernel is available and can be found in scripts/patch-kernel. But as always, you should know what you are doing before using automated tools even more so when it comes to the very core of the operating system, the kernel.
18.1.2. Building the Kernel
There are six steps to building the kernel, and they should be quite painless. All these steps are described in more detail in the following pages.
All these commands are executed from /usr/src/linux, except for step 5, which you can do anywhere.
A README file is included in the kernel sources, which should be located at /usr/src/linux/README on your system. Read it. It contains up-to-date notes on kernel compilation, which may be more current than the information presented here. Be sure to follow the steps described there, using the descriptions given later in this section as a guide. If you have installed the kernel sources from a package included with your distribution, there may also be a file with distribution-specific notes that tells you how your distribution's packagers have configured the kernel, and whether (and how) the kernel changes have been changed from the pristine sources that you can download from the net.
188.8.131.52. Kernel configuration: make config
The first step is to run make config. This executes a script that asks you a set of yes/no questions about which drivers to include in the kernel. There are defaults for each question, but be careful: the defaults probably don't correspond to what you want. (When several options are available, the default will be shown as a capital letter, as in [Y/n].) Your answers to each question will become the default the next time you build the kernel from this source tree.
Simply answer each question, either by pressing Enter for the default, or pressing y or n (followed by Enter). Some questions don't have a yes/no answer; you may be asked to enter a number or some other value. A number of the configuration questions allow an answer of m in addition to y or n. This option allows the corresponding kernel feature to be compiled as a loadable kernel module, as opposed to building it into the kernel image itself. Loadable modules, covered in the following section, "Loadable Device Drivers," allow portions of the kernel (such as device drivers) to be loaded and unloaded as needed on a running system. If you are unsure about an option, type ? at the prompt; for most options, a message will be shown that tells you more about the option.
The system remembers your configuration options each time you run make config, so if you're adding or removing only a few features from your kernel, you need not re-enter all the options.
Some people say that make config has so many options now that it is hardly feasible to run it by hand any longer, as you have to concentrate for a long time to press the right keys in response to the right questions. Therefore, people are moving to the alternatives described next.
An alternative to running make config is make xconfig, which compiles and runs an X-Window-based kernel configuration program. In order for this to work, you must have the X Window System running, have the appropriate X11 and Qt libraries installed, and so forth. Instead of asking a series of questions, the X-based configuration utility allows you to use checkboxes to select which kernel options you want to enable.
Also available is make menuconfig, which uses the text-based curses library, providing a similar menu-based kernel configuration if you don't have X installed. make menuconfig and make xconfig are much more comfortable than make config, especially because you can go back to an option and change your mind up to the point where you save your configuration. However, we'll describe the process here in a linear fashion, as make config does it.
The following is part of a session with make config. When using make menuconfig or make xconfig, you will encounter the same options, only presented in a more user-friendly fashion (we actually recommend the use of these tools if at all possible, because it is very easy to get confused by the myriad of configuration options):
pooh:/usr/src/linux # make config scripts/kconfig/conf arch/i386/Kconfig # # using defaults found in .config # * * Linux Kernel Configuration * * * Code maturity level options * Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] Select only drivers expected to compile cleanly (CLEAN_COMPILE) [Y/n/?] * * General setup * Local version - append to kernel release (LOCALVERSION) [-default] Support for paging of anonymous memory (swap) (SWAP) [Y/n/?] System V IPC (SYSVIPC) [Y/n/?] POSIX Message Queues (POSIX_MQUEUE) [Y/n/?] BSD Process Accounting (BSD_PROCESS_ACCT) [Y/n/?] BSD Process Accounting version 3 file format (BSD_PROCESS_ACCT_V3) [Y/n/?] Sysctl support (SYSCTL) [Y/n/?] Auditing support (AUDIT) [Y/n/?] Enable system-call auditing support (AUDITSYSCALL) [Y/n/?] Kernel log buffer size (16 => 64KB, 17 => 128KB) (LOG_BUF_SHIFT)  Support for hot-pluggable devices (HOTPLUG) [Y/?] y Kernel Userspace Events (KOBJECT_UEVENT) [Y/n/?] Kernel .config support (IKCONFIG) [Y/n/?] Enable access to .config through /proc/config.gz (IKCONFIG_PROC) [Y/n/?] * * Configure standard kernel features (for small systems) * Configure standard kernel features (for small systems) (EMBEDDED) [N/y/?] Load all symbols for debugging/kksymoops (KALLSYMS) [Y/?] (NEW) y Include all symbols in kallsyms (KALLSYMS_ALL) [N/y/?] Do an extra kallsyms pass (KALLSYMS_EXTRA_PASS) [N/y/?] * * Loadable module support * Enable loadable module support (MODULES) [Y/n/?] Module unloading (MODULE_UNLOAD) [Y/n/?] Forced module unloading (MODULE_FORCE_UNLOAD) [Y/n/?] Module versioning support (EXPERIMENTAL) (MODVERSIONS) [Y/n/?] Source checksum for all modules (MODULE_SRCVERSION_ALL) [Y/n/?] Automatic kernel module loading (KMOD) [Y/n/?] * * Processor type and features * Subarchitecture Type > 1. PC-compatible (X86_PC) 2. AMD Elan (X86_ELAN) 3. Voyager (NCR) (X86_VOYAGER) 4. NUMAQ (IBM/Sequent) (X86_NUMAQ) 5. SGI 320/540 (Visual Workstation) (X86_VISWS) choice[1-5]: Processor family 1. 386 (M386) 2. 486 (M486) > 3. 586/K5/5x86/6x86/6x86MX (M586) 4. Pentium-Classic (M586TSC) 5. Pentium-MMX (M586MMX) 6. Pentium-Pro (M686) 7. Pentium-II/Celeron(pre-Coppermine) (MPENTIUMII) 8. Pentium-III/Celeron(Coppermine)/Pentium-III Xeon (MPENTIUMIII) 9. Pentium M (MPENTIUMM) 10. Pentium-4/Celeron(P4-based)/Pentium-4 M/Xeon (MPENTIUM4) 11. K6/K6-II/K6-III (MK6) 12. Athlon/Duron/K7 (MK7) 13. Opteron/Athlon64/Hammer/K8 (MK8) 14. Crusoe (MCRUSOE) 15. Efficeon (MEFFICEON) 16. Winchip-C6 (MWINCHIPC6) 17. Winchip-2 (MWINCHIP2) 18. Winchip-2A/Winchip-3 (MWINCHIP3D) 19. CyrixIII/VIA-C3 (MCYRIXIII) 20. VIA C3-2 (Nehemiah) (MVIAC3_2) choice[1-20]: Generic x86 support (X86_GENERIC) [Y/n/?] HPET Timer Support (HPET_TIMER) [N/y/?] Symmetric multi-processing support (SMP) [N/y/?] Preemptible Kernel (PREEMPT) [N/y/?] Local APIC support on uniprocessors (X86_UP_APIC) [Y/n/?] IO-APIC support on uniprocessors (X86_UP_IOAPIC) [Y/n/?] Disable local/IO APIC by default (X86_APIC_OFF) [Y/n/?] Machine Check Exception (X86_MCE) [Y/n/?] Check for non-fatal errors on AMD Athlon/Duron / Intel Pentium 4 (X86_MCE_NONFATAL) [N/m/y/?] check for P4 thermal throttling interrupt. (X86_MCE_P4THERMAL) [Y/n/?] Toshiba Laptop support (TOSHIBA) [M/n/y/?] ...and so on. .. *** End of Linux kernel configuration. *** Check the top-level Makefile for additional configuration. *** Next, you may run 'make bzImage', 'make bzdisk', or 'make install'.
If you have gathered the information about your hardware when installing Linux, that information is probably sufficient to answer the configuration questions, most of which should be straightforward. If you don't recognize some feature, it's a specialized feature that you don't need.
It should be noted here that not all Linux device drivers are actually built into the kernel. Instead, some drivers are available only as loadable modules, distributed separately from the kernel sources. (As mentioned earlier, some drivers can be either built into the kernel or compiled as modules. In other cases, you have only one choice or the other.)
If you can't find support for your favorite hardware device in the list presented by make config, it's quite possible that the driver is available as a module or a separate kernel patch. Scour the FTP sites and archive CD-ROMs if you can't find what you're looking for. In the next section, "Loadable Device Drivers," kernel modules are covered in detail.
The following questions are found in the kernel configuration for Version 184.108.40.206. If you have applied other patches, additional questions might appear. The same is true for later versions of the kernel. Note that in the following list we don't show all the kernel configuration options; there are simply too many of them, and most are self-explanatory. We have highlighted only those that may require further explanation. Remember that if you're not sure how to answer a particular question, the default answer is often the best choice. When in doubt, it is also a good idea to type ? and check the help message.
Following are the high-level choices and the ramifications of choosing each one.
220.127.116.11. Preparing the ground: make clean
If you wish to force a complete recompilation of the kernel, you should issue make clean at this point. This removes from this source tree all object files produced from a previous build. If you have never built the kernel from this tree, you're probably safe skipping this step (although it can't hurt to perform it). If you are tweaking minor parts of the kernel, you might want to avoid this step so that only those files that have changed will be recompiled. At any rate, running make clean simply ensures the entire kernel will be recompiled "from scratch," and if you're in any doubt, use this command to be on the safe side.
18.104.22.168. Compiling the kernel
Now you're ready to compile the kernel. This is done with the command make bzImage. It is best to build your kernel on a lightly loaded system, with most of your memory free for the compilation. If other users are accessing the system, or if you're trying to run any large applications yourself (such as the X Window System, or another compilation), the build may slow to a crawl. The key here is memory. If a system is low on memory and starts swapping, it will be slow no matter how fast the processor is.
The kernel compilation can take anywhere from a few minutes to many hours, depending on your hardware. There is a great deal of codewell over 80 MBin the entire kernel, so this should come as no surprise. Slower systems with 16 MB (or less) of RAM can expect to take several hours for a complete rebuild; faster machines with more memory can complete it in less than half an hour. Your mileage will most assuredly vary.
If any errors or warnings occur while compiling , you cannot expect the resulting kernel to work correctly; in most cases, the build will halt if an error occurs. Such errors can be the result of incorrectly applying patches, problems with the make config step, or actual bugs in the code. In the "stock" kernels , this latter case is rare, but is more common if you're working with development code or new drivers under testing. If you have any doubt, remove the kernel source tree altogether and start over.
When the compilation is complete, you will be left with the file bzImage in the directory /usr/src/linux/arch/i386/boot. (Of course, if you're attempting to build Linux on a platform other than the Intel x86, the kernel image will be found in the corresponding subdirectory under arch.) The kernel is so named because it is the executable image of the kernel, and it has been internally compressed using the bzip2 algorithm. When the kernel boots, it uncompresses itself into memory: don't attempt to use bzip2 or bunzip2 on bzImage yourself! The kernel requires much less disk space when compressed in this way, allowing kernel images to fit on a floppy. Earlier kernels supported both the gzip and the bzip2 compression algorithms, the former resulting in a file called zImage. Because bzImage gives better compression results, however, gzip should not be used, as the resulting kernels are usually too big to be installed these days.
If you pick too much kernel functionality, you can get a kernel too big error at the end of the kernel compilation. This happens rarely because you need only a very limited amount of hardware support for one machine, but it can happen. In this case, there is one way out: compile some kernel functionality as modules (see "Loadable Device Drivers").
You should now run rdev on the new kernel image to verify that the root filesystem device, console SVGA mode, and other parameters have been set correctly. This is described in "Using a Boot Floppy" in Chapter 17.
22.214.171.124. Installing the kernel
With your new kernel in hand, you're ready to configure it for booting. This involves either placing the kernel image on a boot floppy, or configuring GRUB to boot the kernel from the hard drive. These topics are discussed in "Booting the System" in Chapter 17. To use the new kernel, configure it for booting in one of these ways, and reboot the system.