In recent years, the Linux operating system has achieved success in the desktop and server computing arena that has traditionally been the mainstay of proprietary operating systems from Microsoft (Windows), Sun Microsystems (SunOS/Solaris) and others. The move to Linux can be attributed, at least in part, to lower cost and higher performance. Today’s top-end Pentium class processors run Linux and far outperform similarly priced SPARC-based systems running Solaris. Another major reason for success is the open source nature of Linux (unlike Solaris or Microsoft Windows): users benefit from the collective enhancements of the worldwide Linux community.

Interestingly, vendors of Linux for use in desktop and server computing have mostly defocused from the embedded systems industry. Other vendors, such as Lineo and MontaVista, who have focused on embedded systems, have yet to achieve sustained profitability. What is it about the embedded systems industry that has prevented Linux from attaining the success it has reached on the desktop? The reason lies in the difference in requirements between desktop and embedded systems.

These differences are many and they are significant. We will examine a few of them, not to be exhaustive, but to show examples of challenges faced by embedded systems that desktops do not encounter. Embedded systems requirements differ in the areas of:

• Interrupt latency
• Thread response time
• Scheduling
• Device drivers
• Memory footprint
• Reliability and security

Furthermore, there are a variety of important non-technical considerations that must be taken into account when thinking about using Linux in an embedded device.

Interrupt Latency

By definition, a real-time system is one in which an event (for example, an interrupt from an important peri-pheral device) must be handled within a bounded (and typically short) amount of time; failure to respond causes a failure in the embedded system. Many embedded systems have real-time requirements; desktop systems do not. Along with context switch time, interrupt latency is the most often analyzed and benchmarked measurement for embedded real-time systems. Operating system architecture is the most significant factor for determining interrupt latency and thread response times in an embedded system.

Interrupt latency is defined as the elapsed time between an interrupt and the execution of the first instruction in the corresponding interrupt service routine. Interrupts are typically prioritized (by hardware) and nest; therefore, the latency of the highest priority interrupt is usually examined. How can software increase interrupt latency? By actually deferring interrupt processing during certain “critical” operating system operations. The operating system does this by “disabling” interrupts while it performs such critical sequences of instructions. The major component of worst-case interrupt latency is the number and length (in terms of time to execute those instructions) of these sequences.

If an interrupt occurs during a period of time in which the operating system has disabled interrupts, the interrupt will remain pending until software re-enables interrupts (Figure 1). The length of time for which interrupts are disabled provides a worst-case upper bound for interrupt latency.

The importance of understanding the worst-case interrupt disabling sequence must not be understated. A real-time system utterly depends upon guaranteeing that the critical events in the system are handled within the required time frame. The reality, however, is that operating system vendors generally publish an average, typical or best-case interrupt latency, measured in a lab environment. Is it possible to statically compute the worst-case disabling region? A team of Swedish researchers (see http://citeseer.nj.nec.com/carlsson02worstcase.html" target="_blank">http://citeseer.nj.nec.com/carlsson02worstcase.html) recently attempted to discover the answer to this question for one commercial real-time operating system in use today.

The case study employed some advanced methods of program flow analysis in an attempt to determine the location and structure of all the interrupt disabling regions. The researchers used cycle accurate models to determine execution counts of the selected regions. The case study took five months to complete.

The results are not encouraging. Because the microprocessor instruction used to disable and enable interrupts uses a variable register value as its source, it was often impossible to statically determine whether a given instruction enabled or disabled interrupts. Other problems of program flow, such as nested disabling/