The default kernel configuration varies from one Linux distribution to the next. They generally try to provide a good balance between hardware support, kernel size, and speed. Each Linux vendor tries to meet the needs of the "average user". RedHat for example, packages a kernel with a wide array of hardware, filesystem, and networking support.

Why am I doing this again?

Why bother recompiling the kernel? If you do some reading on the subject, several situations will become apparent:

• Bug Fixes - Hardware bugs which could lead to system failure. A patch is generally released quickly, a recompile solves the problem.
• Hardware Support - A device in your system is currently not supported by your running kernel. Either compile support for the device in question directly into your kernel or compile support as a module.
• Program Dependency - You want to run a certain program but the operating system tells you the kernel doesn't support a feature it needs to function.
• Security Alert - You sit by your inbox watching bugtraq and you see a security alert which is quickly solved via a kernel patch. You remake your kernel to ensure security.
• Desired Kernel Feature - Want to have +1GB of RAM in your Linux system? Well, you're gonna have to recompile.

These are a few of the main reasons one would recompile their kernel. One major reason that is often left out of the literature, is sheer performance. What hardware in your high-load server has the biggest impact on overall system performance? RAM and disk-speed. That being said, it is very obvious why reducing memory consumption by the kernel is important. You can really optimize the kernel so that it not only runs better on the machine in question, but also consumes less RAM. We'll come back to this, right now we have to talk about the requirements for one to recompile, and about the kernel configuration itself.

What do I need?

All right, you are PRIMED to recompile that kernel of yours, but you can't just jump into it. You have to ensure several key packages are installed on your Linux system. First thing on your "to do" list is to ensure that the kernel headers and kernel source code are installed properly. Once you've got the source unpacked to /usr/src/linux you "should" paruse the documentation. It has detailed information (version numbers and everything, wow) on what files you'll need installed on your system to compile the source you just unpacked. Seeing as how I'm such a nice guy, I'll give you a brief synopsis of what you'll need.

• make
• C compiler (gcc or egcs)
• bin86 (x86 assembler)
• ncurses (if you intend on using 'make menuconfig')

Let the configuration begin…

Alright, at this point, you've got the Kernel source unpacked, you've scanned the documentation, and you have all packages required to compile installed… we hope. Now, you have to decide on what method you will use to configure your kernel. There are three ways.

• make config - Straight command-line interface. It asks questions one at a time about what you want in your kernel. Its biggest downfall is, you cannot go back to a previous question, so if you make a mistake, you have to start at the beginning (Did I mention there are a LOT of questions?).
• make menuconfig - Menu-based kernel configuration. This is what I prefer. It allows you explore through and select options as you go. You can return to any previous area.
• make xconfig - GUI Kernel configuration. It allows mouse clicks through graphical menus. You have to be running X Windows. To be honest, I've never used it.

*'s, M's and other nonsense

As you're scanning through the various options presented to you by whichever configuration method you've selected (See above.); it is of the utmost importance one understands how each can be applied to the kernel. Kernel options fall into one of two categories: Module-capable and Non-module-capable. (note - kernel modules allow you to add certain functionality or hardware support to Linux. It isn't a part of the kernel itself, but can be added or removed from the running kernel at any time.) If, an option is Non-module-capable it must be either included as a part of the kernel itself or not included at all.

Ok… Let's break down the configuration options.

<*> - this will include that option as part of the running kernel itself, always a part of the system.

< > - leaving an option blank means it won't be included in the kernel or created as a module.

< M > - the option will be included as a module, but not part of the kernel itself.

It should be relatively clear why modular kernels are so popular. It allows the user to retain a relatively small kernel, but still have the support and functionality they need. However a modular kernel isn't the only option presented to the user. You can configure your kernel so that each option is compiled directly into it. This is called a monolithic kernel.

This being said, why would anyone choose a monolithic kernel over a modular one? Compiling every option into the kernel would increase kernel size and therefore increase memory consumption. Let us take a simple Linux gateway as an example: The box won't be overloaded on expansion cards. Only a cheap video adapter and 2 network cards (we'll even leave SCSI out of the picture). All this box will do is masq a small internal LAN. You hack your kernel configuration apart, leaving ONLY the necessary support and networking options. Your kernel size has decreased dramatically so what does it matter to compile support for your two network cards directly into the kernel (as opposed to modules). The problem with loading kernel options as modules is that sometimes… modules… don't load. With everything compiled directly into the kernel, this is not a worry.

At this point, hopefully you have your kernel configuration complete. Exit and save your configuration. (note - your kernel configuration is stored in /usr/src/linux/.config)