> initrd.txt — Chapter 34 also discusses the initial RAM disk. This file provides much more in-depth knowledge of initial RAM disks, 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 ashttp://www.google.com/linux.
> sysrq.txt — If you have ever wondered what that SysRq key on your keyboard is 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 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
After a kernel is built, all the compiled files 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.
The make utility is a very complex program. Complete documentation on the structure of Makefiles, as well as the arguments that it can accept, can be found at http://www.gnu.org/software/make/manual/make.html.
The remaining directories 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 does 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 nonprogrammer might be able to get an idea of what the application or driver is actually doing (see Chapter 28, '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.
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 hard ware, 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 because 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
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
The typical Fedora 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 available only after the system has been booted.
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 section '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 be only 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 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.
Managing Modules
With a modular kernel, special tools are required to manage the modules. Modules must be loaded and unloaded, and it would be nice if that were done as automatically as possible. You also need to be able to pass necessary parameters to modules when you load them — things such as memory addresses and interrupts. (That
