Kernel Features
The Linux kernel runs on a vast array of hardware architectures—everything from handhelds to mainframes. To support this sort of scalability, the kernel is highly configurable.
There are several ways of configuring the kernel (note that I’m using the word configure quite loosely here):
Typing make config, make menuconfig, or make xconfig in the root of the kernel source runs the standard kernel configure routines. You can turn options on or off or sometimes compile them as modules so they can be loaded at runtime.
There are hundreds—perhaps even thousands—of kernel patches floating around the Internet. Some are very small—enough to fix a small bug in one file. Medium-size patches may affect a half-dozen files and add support for a particular hardware device. Some large patches add or affect many dozens of files and add support for new architectures. Often applying a patch adds new questions or entire screens to the kernel-configuration screens previously described.
The One True Method of really “configuring” the kernel to do exactly what you want is to hack on it yourself. Until recently, this was an exercise only for those who have lots of time and patience—the Linux kernel source code is well structured but somewhat obtuse. Linus doesn’t believe in cluttering up the source with comments for the uninitiated (see Chapter 5 of Documentation/Coding Style in the Linux source tree).
Fortunately, times have changed and there are now several good overviews of the Linux kernel. Perhaps the most lucid is Understanding the Linux Kernel by Daniel Pierre Bovet and Marco Cesati (O’Reilly, 2000).
Networking, Filesystems, and Executable Formats
Some embedded Linux applications have no use for the networking code. Be sure to configure the kernel so that the networking code is skipped if you don’t need it; it takes up a lot of space. Also, make sure that your kernel supports only the one or two filesystem types you actually need. Finally, you probably need only one executable format, ELF (Executable and Linking Format), for your embedded application, so be sure to turn off all the rest. For details on the ELF file format, consult the following documents:
In general, it’s a good idea to look through the documentation for all the choices in the kernel build menu. If you’re using make menuconfig to configure the kernel, you can press the question mark ( ? ) at any time to get information on the choice you have highlighted.
While you’re developing your embedded device, it’s handy to enable loadable module support in the kernel. That way, if you need support for a feature that you hadn’t anticipated, you can go back, recompile the modules you need, copy them onto your device, and load them. Without loadable module support, you have to recompile the whole kernel, which can be a bit of a pain. When you’re done developing the device, you can save some amount of RAM and ROM space by recompiling the kernel without loadable module support and with your drivers compiled directly into the kernel. However, you should figure out exactly how much of a savings this is and whether it’s worth it—having loadable module support may be useful for upgrading drivers in the field.
Execute-in-Place (XIP)
One way you may be able to save a lot of RAM requirements is to run your executable programs directly from the long-term storage (ROM or flash) where they reside. This is called execute-in-place (or XIP for short).
On a desktop system, your application lives on the hard disk and must be read into RAM for execution. However, most embedded applications don’t have a hard drive for long-term storage; instead, they have some sort of memory device, such as ROM or flash. Unlike a hard drive, these memory devices may be directly addressable by the CPU, like RAM. You can use the direct addressability of these memory devices to reduce your RAM requirements. Instead of copying the executable code from the memory device into RAM, an XIP system sets up the kernel structures that normally point into the RAM copy directly at the long-term storage locations. The code executes just as it would if it were copied to RAM. Depending on the speed of the processor, memory, and flash, there could be a performance penalty for using XIP.
Figure 1.1 shows the difference between normal execution and execution in place (XIP):
Figure 1.1. XIP illustration.
Real-Time Operating Systems
Most of the time, it’s not very important exactly how long a specific task takes to complete on a computer. For instance, when someone hits a key on the keyboard, they expect a letter to appear “instantly”—but how fast is “instantly”? It could be anywhere from a few tens of milliseconds to a couple of hundred milliseconds. You’re probably not going to notice the difference between any two timings under 50 milliseconds (about 1/20th of a second). However, the timing of some operations in some computer applications is crucial. For instance, if your application moves a robotic arm to a precise location so that it can pick up a chip from a stack, then to another location so it can lay down the chip at a precise location on a PC board, the timing of the movement operations must be exact. This is when you need a real-time OS.
For instance, most modern cars have antilock braking systems. In these systems, special sensors detect when one or more wheels begin to “lock up”—a dangerous situation that can cause the vehicle (and its occupants!) to slide. In these situations, it’s imperative that when the sensors detect a wheel beginning to lock, the braking on that wheel be reduced immediately. Have you ever worked on a computer system where you started a new program and the entire computer became unresponsive for several seconds? Imagine what would happen if the computer controlling your antilock brakes was similarly busy and unresponsive—right when a deer jumped in front of your car! This is a situation where you need what’s called hard real time .
A hard real-time OS guarantees that, without fail, no matter what else happens, a response to an event will occur within a specified fixed time. For example, when wheel lockup is detected, braking for that wheel must be reduced within a certain number of milliseconds. In this example, a hard limit exists on how long the system can take to respond to the wheel lockup condition. This hard limit means that this is a hard real-time task—first, because there’s an absolute limit on the amount of time available for a response, and second, because bad things will happen if the system fails to respond within the specified time limit. These two features of the task to be performed make it clear that the task requires a hard real-time operating system.
When working with a soft real-time OS, on the other hand, when an event occurs the system will try its best to service the event within an average response time. For example, when playing a game of Quake III, when a player fires a rocket at another player there’s an expectation that the game program will draw a fiery explosion onscreen, make explosion noises, and dutifully subtract health from your opponent. With all of this complexity added to the existing events in the game, it’s very likely that the frame rate of the game may drop slightly while rendering the explosion and playing back the additional audio, since these tasks require additional CPU time. If the frame rate should drop from 50 frames per second (fps) to, say, 40 fps for the duration of the explosion, no harm is done—the player continues to enjoy her game, since the system is still “fast enough.” Being “fast enough” is a defining characteristic of soft realtime systems. In this case, no fixed frame rate is required of the system, and no harm occurs should the frame rate decrease slightly.
Both hard and soft real-time systems are useful, but they have distinctly different uses. In fact, a hard real-time OS usually accommodates tasks requiring both hard and soft real-time response.
Several attributes differentiate a real-time operating system from a standard operating system, as shown in the following list.
Response time predictability. A hard real-time OS guarantees that the timing of some operations will be precise within its stated limitations. These response times are much faster than those of a typical operating system—they’re measured in tens of microseconds (millionths of a second) instead of milliseconds (thousandths of a second).
Schedulability. In a hard real-time operating system, a process can be scheduled to perform at a very precise time in the future or at a very precise interval. Again, the precision is down to the microsecond level instead of the millisecond level.
Stability under pressure. In a hard real-time system, the processor can become inundated with far more signals from different sources than it can handle; however, some of those signals are much more important than other signals and must be recognized and dealt with.The ability to prioritize a vast array of different signals quickly and efficiently is another hallmark of a good real-time system.
For more details on embedded real-time systems, see Raj Rajkumar, et al, The Concise Handbook of Linux for Embedded Real-Time Systems Version 1.0 (Pittsburgh, Pennsylvania: TimeSys Corporation, 2000), p. 5. In addition, www.RealTimeLinux.org provides a lot of information about real-time Linux.
Several real-time Linux kernel projects are underway, as shown in Table 1.1 .
| Address | Title | Site Sponsor |
|---|---|---|
| www.rtlinux.org | RTLinux—Real time Linux | New Mexico Institute of Technology |
| http://server.aero.polimi.it/projects/rtai/ | RTAI—Real Time Application Interface | Dipartimento di Ingegneria Aerospaziale Politecnico di Milano |
| www.ittc.ukans.edu/kurt/ | KURT—The KU Real Time Linux | University of Kansas |
| http://linux.ece.uci.edu/RED-Linux/index.html | RED-Linux | University of California, Irvine |