【正文】 d it’s easier to maintain the integrity of the system.Real Time PerformanceThe term “real time” is bandied about a lot, so I’ll define what it implies in this paper before I describe the real time features of Linux. By “real time” I mean the ability to put deterministic bounds on the time the elapses between an interrupt occurring and the corresponding interrupt service routine to execute. Other items, such as context switch time and system clock granularity, are related, but not central, issues.In general, real time performance can be grouped into two broad categories: hard real time and soft real time. Hard real time means that a late answer is a wrong answer. If the system does not respond to an interrupt within a fixed, predictable amount of time disastrous things can happen. Soft real time, on the other hand, doesn’t have any dire consequences associated with a late answer but relies on deterministic timing of interrupt handlers to achieve top performance. It’s important to remember that although the actual performance numbers are important, real time characteristics are actually more about deterministic behavior than raw speed.The bare Linux kernel is not real time. No guarantees are provided for deterministic interrupt handling times and the numbers can vary greatly depending on what the system load is when the interrupt occurs. RTLinux was designed to add hard real time characteristics to the Linux kernel.First released in February 1997 by Michael Barabanov and Victor Yodaiken of the New Mexico Institute of Technology, RTLinux is not a separate, modified version of the Linux kernel. After considering this possibility, it was deemed to be a maintenance and patibility nightmare2. Instead RTLinux was designed as a small, independent realtime kernel and a set of replacements for the Linux kernel routines that enable and disable interrupts. RTLinux also supplies an API that allows the user to create tasks in the realtime kernel and municate with processes in the Linux kernel via FIFOs or shared memory. Figure graphically depicts how the system works. When RTLinux is included and the Linux kernel calls the CLI or STI to disable enable interrupts, respectively, the request gets routed to an RTLinux routine that remembers the current Linux interrupt state. When interrupts occur they are always handled by the RTLinux kernel and are then passed on to the Linux kernel if they were not handled and interrupts are enabled. This allows RTLinux to always react to every interrupt without the Linux kernel getting in the way. This also gets around the problem of the Linux kernel not being able to handle nested interrupts since RTLinux always sees the interrupt first and can ensure that the kernel is never reentered.RTLinux is not the only player in this arena. Real Time Application Interface (RTAI) takes a similar approach in extending the existing Linux kernel with real time features. They have a few features, such as periodic timers, that are not present in RTLinux but do not have the wide popularity of RTLinux. If you believe the rumors, these two products will merge in some future version.There are some problems with the features present in both RTLinux and RTAI. First of all it is clear that the features were bolted on as an afterthought instead of being an intrinsic part of the design. Although RTLinux does an admirable job of acplishing it’s goals it tends to be useful in certain classes of applications such as data acquisition rather then being more generally applicable. Another issue is that RTLinux does nothing to address the problem of priority inversion, which can be the cause of serious bugs that are hard to reproduce and track down. RealTime FIFOsInterrupt Control HardwareRealTime KernelRealTime TasksLinuxLinux Processes Figure 1: Block Level design of RTLinuxGraphical User InterfacesAs the desktop puter has e to rely on GUIs rather than text based interfaces, many embedded systems have also been adopting them. A GUI in an embedded system may e in many different flavors including small resolution LCDs, an optional VGA output port, or a fully integrated screen with either vertical or horizontal orientation. Although similar in concept to desktop GUIs, embedded systems have some requirements, such as the kernel footprint, that are uniquely their own.Linux has always suffered from a fragmented market in the area of GUIs. Although the XWindow the closest thing to a standard, there are many popular petitors including emulators for the Win32 API and the look and feel of Windows 95. Embedded systems are certainly free to use any of these systems that are targeted for the desktop, but there are several products that specifically target the unique needs of embedded systems.Lineo Systems is one provider of a version of embedded Linux with enhancements and mercial support. One of the options that they provide is a custom toolkit for building an embedded GUI. Microwindows and NanoGUI are two public, open source projects that were merged to provide a free library for emulating the Win32 API for use on Linux systems. There are certainly other options – these are just the tip of the iceberg.There is another, separate route that many embedded devices have chosen to take when providing a GUI. Since network and Internet connectivity are so mon these days, many systems choose to include a web server and offer up their user interface via HTML. This allows the user to access the device remotely from any location with any platform that has a web browser. It also places fewer requirements on the size and shape of the device since it doesn’t have to include a display. Development Tool SupportEmbedded Linux developers get the best of both worlds when it es to development tools. Not only do they get to utilize the same GNU tool chain a