The Linux Kernel

The Linux kernel is the management part of the operating system that many people call "Linux." Although many think of the entire distribution as Linux, the only piece that can correctly be called Linux is the kernel. Fedora Core Linux, like many Linux distributions, includes a kernel packaged with add-on software that interacts with the kernel so that the user can interface with the system in a meaningful manner.

The system utilities and user programs enable computers to become valuable tools to a user.

The First Linux Kernel

In 1991, Linus Torvalds released version .99 of the Linux kernel as the result of his desire for a powerful, Unix-like operating system for his Intel 80386 personal computer. Linus wrote the initial code necessary to create what is now known as the Linux kernel and combined it with Richard Stallman's GNU tools. Indeed, because many of the Linux basic system tools come from the GNU Project, many people refer to the operating system as GNU/Linux. Since then, Linux has benefited as thousands of contributors add their talents and time to the Linux project. Linus still maintains the kernel, deciding on what will and will not make it into the kernel as official releases, known to many as the "vanilla" or "Linus" Linux kernel.

The Linux Source Tree

The source code for the Linux kernel is kept in a group of directories called the kernel source tree. The structure of the kernel source tree is important because the process of compiling (building) the kernel is automated; it is controlled by scripts interpreted by the make application. These scripts, known as makefiles, expect to find the pieces of the kernel code in specific places or they will not work. You will learn how to use make to compile a kernel later in this chapter.

It is not necessary for the Linux kernel source code to be installed on your system for the system to run or for you to accomplish typical tasks such as email, web browsing, or word processing. It is necessary that the kernel sources be installed, however, if you want to compile a new kernel. In the next section, we will show you how to install the kernel source files and how to set up the special symbolic link required. That link is /usr/src/linux-2.6, and it is how we will refer to the directory of the kernel source tree as we examine the contents of the kernel source tree.

The /usr/src/linux-2.6 directory contains the .config and the Makefile files among others. The .config file is the configuration of your Linux kernel as it was compiled. There is no .config file by default; you must select one from the /configs subdirectory.

There, you will find configuration files for each flavor of the kernel Fedora provides; simply copy the one appropriate for your system to the default directory and rename it .config.

We have already discussed the contents of the /configs subdirectory, so let us examine the other directories found under /usr/src/linux-2.6. The most useful for us is the Documentation directory. In it and its subdirectories, you will find almost all the documentation concerning every part of the kernel. The file 00-INDEX (each Documentation subdirectory also contains a 00-INDEX file as well) contains a list of the files in the main directory and a brief explanation of what they are. Many files are written solely for kernel programmers and application writers, but a few are useful to the intermediate or advanced Linux user when attempting to learn about kernel and device driver issues. Some of the more interesting and useful documents are

devices.txt A list of all possible Linux devices that are represented in the /dev directory, giving major and minor numbers and a short description. If you have ever gotten an error message that mentions char-major-xxx, this file is where that list is kept. Devices are mentioned in Chapter 37, "Managing the File System."

ide.txt If your system uses IDE hard drives, this file discusses how the kernel interacts with them and lists the various kernel commands that can be used to solve IDE-related hardware problems, manually set data transfer modes, and otherwise manually manage your IDE drives. Most of this management is automatic, but if you want to understand how the kernel interacts with IDE devices, this file explains it.

initrd.txt Chapter 37 also discusses the initial ramdisk. This file provides much more in-depth knowledge of initial ramdisks, giving details on the loopback file system used to create and mount them and explaining how the kernel interacts with them.

kernel-parameters.txt This file is a list of most of the arguments that you can pass at boot time to configure kernel or hardware settings, but it does not appear too useful at first glance because it is just a list. However, knowing that a parameter exists and might relate to something you are looking for can assist you in tracking down more information because now you have terms to enter into an Internet search engine such as http://www.google.com/linux.

sysrq.txt If you have ever wondered what that key on you keyboard marked "SysRq" was used for, this file has the answer. Briefly, it is a key combination hardwired into the kernel that can help you recover from a system lockup. Fedora Core disables this function by default for security reasons. You can re-enable it by entering the command # echo "1" > /proc/sys/kernel/sysrq and disable it by echoing a value of 0 instead of 1.

In the other directories found in Documentation, you will find similar text files that deal with the kernel modules for CD-ROM drivers, file system drivers, gameport and joystick drivers, video drivers (not graphics card drivers those belong to X11R6 and not to the kernel), network drivers, and all the other drivers and systems found in the Linux operating system. Again, these documents are usually written for programmers, but they can provide useful information to the intermediate and advanced Linux user as well.

The directory named scripts contains many of the scripts that make uses. It really does not contain anything of interest to anyone who is not a programmer or a kernel developer (also known as a kernel hacker).

After a kernel is built, all the compiled files will wind up in the arch directory and its subdirectories. Although you can manually move them to their final location, we will show you later in this chapter how the make scripts will do it for you. In the early days of Linux, this post-compilation file relocation was all done by hand; you should be grateful for make.

Note

The make utility is a very complex program. Complete documentation on the structure of make files, as well as the arguments that it can accept, can be found at http://www.gnu.org/software/make/manual/make.html.

The remainder of the directories in /usr/src/linux-2.6 contain the source code for the kernel and the kernel drivers. When you install the kernel sources, these files are placed there automatically. When you patch kernel sources, these files are altered automatically. When you compile the kernel, these files are accessed automatically. Although you never need to touch the source code files, they can be useful. The kernel source files are nothing more than text files with special formatting, which means that we can look at them and read the programmers' comments. Sometimes, a programmer will write an application, but cannot (or often will not) write the documentation. The comments he puts in the source code are often the only documentation that exists for the code.

Small testing programs are even "hidden" in the comments of some of the code, along with comments and references to other information. Because the source code is written in a language that can be read as easily almost as English, a non-programmer might be able to get an idea of what the application or driver is actually doing (see Chapter 32, "C/C++ Programming Tools for Fedora"). This information might be of use to an intermediate to advanced Linux user when he is confronted by kernel- and driver-related problems.

Note

The interaction and control of hardware is handled by a small piece of the kernel called a device driver. The driver tells the computer how to interact with a modem, a SCSI card, a keyboard, a mouse, and so on in response to a user prompt. Without the device driver, the kernel does not know how to interact with the associated device.

Types of Kernels

In the early days of Linux, kernels were a single block of code containing all the instructions for the processor, the motherboard, and the other hardware. If you changed hardware, you were required to recompile the kernel code to include what you needed and discard what you did not. Including extra, unneeded code carried a penalty since the kernel became larger and occupied more memory. On older systems that had only 4MB 8MB of memory, wasting precious memory for unnecessary code was considered unacceptable. Kernel compiling was something of a "black art" as early Linux users attempted to wring the most performance from their computers. These kernels compiled as a single block of code are called monolithic kernels.

As the kernel code grew larger and the number of devices that could be added to a computer increased, the requirement to recompile became onerous. A new method of building the kernel was developed to make the task of compiling easier. The part of the kernel's source code that composed the code for the device drivers could be optionally compiled as a module that could be loaded and unloaded into the kernel as required. This is known as the modular approach to building the kernel. Now, all the kernel code could be compiled at once with most of the code compiled into these modules. Only the required modules would be loaded; the kernel could be kept smaller, and adding hardware was much simpler.

The typical Fedora Core kernel has some drivers compiled as part of the kernel itself (called in-line drivers) and others compiled as modules. Only device drivers compiled in-line are available to the kernel during the boot process; modular drivers are only available after the system has been booted.

Note

As a common example, drivers for SCSI disk drives must be available to the kernel if you intend to boot from SCSI disks. If the kernel is not compiled with those drivers in-line, the system will not boot because it will not be able to access the disks.

A way around this problem for modular kernels is to use an initial Ram disk (initrd) discussed later in "Creating an Initial RAM Disk Image." The initrd loads a small kernel and the appropriate device driver, which then can access the device to load the actual kernel you want to run.

Some code can only be one or the other (for technical reasons unimportant to the average user), but most code can be compiled either as modular or in-line. Depending on the application, some system administrators prefer one way over the other, but with fast modern processors and abundant system memory, the performance differences are of little concern to all but the most ardent Linux hackers.

When compiling a kernel, the step in which you make the selection of modular or in-line is part of the make config step that we will detail later in this chapter. Unless you have a specific reason to do otherwise, we suggest that you select the modular option when given a choice. The process of managing modules is addressed in the next section because you will be managing them more frequently than you will be compiling a kernel.