|< Day Day Up >|
Recipe 10.2. Adding New Features to the 2.4 Kernel
You want to add some new feature to your existing 2.4 kernel, such as support for new hardware, new filesystems, or additional networking capabilities. For example, you've just finally gotten around to buying a USB drive for backup, and you've never used USB before. How do you find out whether your system supports USB now? And how do you add it if it doesn't?
The prerequisites are:
$ uname -r 2.4.22
Unpack the new kernel sources into a folder in your home directory, such as ~/src:
$ tar xvjf linux-2.4.22.tar.bz2
Edit the new kernel makefile (~/src/linux-2.4.22/Makefile), giving a custom value to EXTRAVERSION, such as EXTRAVERSION = -new-kernel.
Run the following commands from ~/src/linux-2.4.22:
$ make mrproper
Copy your .config file to ~/src/linux-2.4.22 now.
Next, configure the new kernel. The configurator will ask many questions. This is where you select the new features you want:
$ make oldconfig
Then run these commands:
$ make dep $ make bzImage $ make modules $ su # make modules_install # cp ~/src/linux-2.4.22/arch/i386/boot/bzImage /boot/vmlinuz-2.4.22-new-kernel # cp ~/src/linux-2.4.22/System.map /boot/System.map-2.4.22-new-kernel
title Kernel 2.4.22, new kernel root (hd0,0) kernel /boot/vmlinuz-2.4.22-new-kernel root=/dev/hda1 ro
image=boot/vmlinuz-2.4.22-new-kernel label=Kernel 2.4.22, new kernel root=/dev/hda1 read-only
And remember to re-run LILO, to write the new configuration to the boot record:
Save a copy of your new .config file in a directory outside of the build tree, so that it does not get deleted or overwritten. Give it a unique, helpful name:
$ cp ~/src/linux-2.4.22/.config ~/kernel-configs/.config-2.4.22-jan-04
You can also add coments to the .config file itself, to help you keep track:
# Automatically generated by make menuconfig: don't edit # # jan 2004 added udf r/w support, jfs, and xfs
When you're satisfied that the new kernel works correctly, you can delete the old kernel, its /lib/modules/$VERSION directory, the build tree, and its bootloader entries (or you can hang on to them, if you prefer).
A lot of documentation tells you to put your kernel sources and build tree in /usr/src/linux. This is a bad idea. As the kernel Readme states: "Do NOT use the /usr/src/linux area! This area has a (usually incomplete) set of kernel headers that are used by the library header files. They should match the library, and not get messed up by whatever the kernel-du-jour happens to be." And you don't want to abuse rootly powers by using a directory that requires root access. A kernel can be built anywhere, even on a completely separate PC.
10.2.3.1 Finding .config
If you've previously built a kernel on your system, you'll find the .config file in the top-level directory of the old build tree. If you have not built a kernel on the system, look in /boot for .config, as most distributions put it there. If you find one in /usr/src/linux, it's most likely a generic .config, and not useful to you.
If there is not a .config file for your system, skip ahead to Recipe Recipe 10.3, because you'll have to configure your new kernel from scratch. make oldconfig will still work, but it will use the defaults in the build tree, which will not suit your system at all. make oldconfig tells you which file it is using:
$ make oldconfig ... # Using defaults found in arch/i386/defconfig
You don't want to use that one! It should say this:
# Using defaults found in .config
10.2.3.2 Explanations of the build commands
Documentation/Changes recommends using gcc 2.95.3. Most newer distributions ship with 3.x, which ought to work, but if you have problems you can install more than one version of gcc on your system, and select the one you want to use at compile-time:
$ make bzImage CC=gcc-2.95.3
make mrproper cleans the build tree to a pristine state, removing configuration files, dependency information, and object files. Do this even with freshly downloaded sources. (mrproper, according to Linux lore, is named for Mr. Proper. Mr. Proper is the European version of Mr. Clean, for those occasions when you need to make something cleaner than clean.) mrproper cleans the build tree more thoroughly than make clean, which removes object files but does not touch configuration or dependency files. Read the Makefile to see exactly what files are removed.
make oldconfig reuses your existing kernel configuration. When you're making a minor addition to your kernel, make oldconfig lets you whiz right through and only asks about new things. It will not let you change any existing settings. "y/n/m/?" means "yes, build this into the kernel / no, do not add this feature / yes, add this as a module / help, please."
If you don't know what to choose, hit ? for help.
make dep builds all the necessary dependencies.
make bzImage compiles the new kernel. This can take up to an hour, depending on the speed of your PC and how complex your new kernel is.
make modules compiles all of the necessary modules.
make modules_install is the first operation that requires superuser privileges. For this example, your new modules are installed into /lib/modules/2.4.22.
cp ~/src/arch/i386/boot/bzImage /boot/vmlinuz-2.4.22-new-kernel copies your nice new kernel image to the /boot directory, and renames it. It is important, when installing multiple kernels, to make sure each one has a unique name and to use the same kernel name in your bootloader.
cp ~/src/System.map /boot/System.map-2.4.22-new-kernel copies the new System.map to /boot. Be sure that the System.map has the same version number as the kernel to which it belongs. The System.map is a symbol table that maps kernel addresses to human-readable names. For example:
c01001f8 t int_msg c0100210 t ignore_int c0100232 t idt_descr
The kernel is happier with numbers, while human coders do better with names. This map keeps everyone happy. If you are running multiple kernels on a system, each kernel needs its own System.map. If you have the wrong System.map, the consequences are not dire. You'll occasionally see the "System.map does not match actual kernel" error message, and you won't get accurate kernel debugging if you need to troubleshoot.
10.2.4 See Also
|< Day Day Up >|