Product SiteDocumentation Site

Chapter 7.  Step Five: Low-Latency Kernel

7.1. Compiling the Linux Kernel
7.1.1. Setting Real-Time Priorities
Have you ever wondered what happens when you boot up your computer? Well, generally, the power button that you press to turn your computer on completes a electrical circuit to ensure that power is supplied to the circuits in the computer. Once this happens, the first thing to "come to life" is the BIOS (on a traditional PC) or the firmware (on certain brands of computers). The BIOS or firmware is tasked with finding some computer code to execute; it does this by looking on various boot devices, such as the harddrives, the optical drive, attached usb sticks, and so on, until it finds a recognizable, bootable block of code.
Once bootable code is found, it assumes control over the computer and starts booting the operating system on that hard drive. Thus, the kernel starts its work of probing the system to learn what hardware (motherboard, CPU, RAM, graphics card, optical drives, web cameras, and so on) it has to control. A kernel is able to control hardware with the use of drivers or "kernel modules". If three is hardware that the kernel does not know how to control, then you will not have access to those components once the computer has completed booting.

Note

Sometimes, devices are universal enough that one generic driver will control it. If there are specialized features that the manufacturer snuck in on top of the universal feature set, however, you may find you won't have access to those if your kernel only has access to a generic driver.
Once the kernel has identified all of the components it has to control, it performs an initialization process that starts up all the services and programs that the operating system needs to run, such as the networking daemon to provide your computer with an IP address, or the system log daemon to record system messages, and so on.
Once the operating system is up and running, the kernel still has work to do. It must manage all of the many tasks happening during normal computer use; plugging in new devices, accessing data on drives, starting up new programs, playing sounds, and so on. It's a complex job and yet the Linux kernel manages to juggle all of the millions of processes computers must do as we use them.
Part of the cost of managing so many concurrent tasks is that each computer process must play nicely with one another. Modern computer users, for instance, expect to be able to play music as they type up documents or create graphics; they do not expect their music to pause each time they save their document or use a fancy graphics filter on the photograph they're re-touching. For multimedia producers, it's essential that multimedia tasks be given top priority so that a reverb filer effect, for instance, is not interrupted, or so that there is no latency while doing overdubs.
Traditionally, this has not been the main focus of the Linux kernel. Ever flexible, the Linux kernel could always be modified to account for audio lagging and other multimedia abberations, but during these Dark Ages it was necessary to download low-latency kernel patches from obscure repositories, manually patch the kernel, and then re-compile and re-install.
These issues are ancient history now. The Linux kernel version 2.6.38.4 received a 200-line block of code that drastically changed its ability to work with near-realtime performance, and multimedia producers haven't looked back since.

Note

The terms "real time" and "low latency" are not the same. On the internet, you will see the two terms used inter-changeably. If you truly need a real-time kernel, then you can still download real-time patches for certain kernel versions and re-compile your kernel. However, it's rare that people need true real-time; low-latency is almost always sufficient.
If you really do need a real-time kernel rather than a low-latency, find the real-time patches at http://kernel.org/pub/linux/kernel/projects/rt/
Therefore, there are two reasons why you might want or need to compile a kernel:
  1. You are using a version of Slackware that did not ship with a kernel 2.6.38.4 or above
  2. You have some unique combination of hardware, or very new hardware, that requires new drivers than those included with the default kernel
In those two cases, compiling a new kernel is simpler than its reputation. In fact, there is a discouraging mythology against compiling kernels, but Slackware has always made the process quite easy. Slackware (or any operational Linux system) already contains a config file for the kernel in use, making a re-compile a trivial task.
You can alternately check the Slackware changelogs (some Slackware users set their architecture's changelog as their web browser home page in order to stay informed) at slackware.com/changelog to find the latest pre-compiled kernel packaged as a downloadable, installable binary (via installpkg); no compiling necessary.