May 2001

Battle for the Unseen Computer

Continued from page 2

By Claire Tristram

The Anti-Liunx

Greg Rose is an odd person to be talking about the limitations of Linux in the embedded market. His company, LynuxWorks, sells it. But the San Jose, CA, outfit is hedging its bets by also selling LynxOS, a proprietary operating system for embedded computing.

While operating systems for embedded devices have remained below the radar screen for most of us, they are technologically elegant. They typically need only kilobytes of memory instead of the megabytes that desktop computer systems like Windows hog. And they can run without anyone telling them what to do-many are in "headless" configurations where there isn't even a user interface. Embedded systems are also built to be fail-safe. After all, a system freeze on a PC is merely an irritation; a glitch in the computer that controls your antilock brakes could be catastrophic.

These operating systems must also be able to perform tasks within a guaranteed window of time. To do this, they interrupt noncritical tasks to make way for critical ones. This feature is known as "real-time" performance. Think automobile bumpers that warn you when you're about to back into something: it doesn't do much good if the alert arrives a second too late. At a refinery that's turning crude oil into gasoline, you end up with a big, charred hole in the ground if the right valves don't close when they are supposed to.

It is just such real-time operation that skeptics say eludes Linux. Linux is built to run a given command from start to finish. That's why the embedded systems that run on Linux to date are ones where real time is not critical, such as the Kerbango radio. Disagreement about the best way to make Linux real-time-and whether it's possible to make Linux real-time at all-are splintering the embedded-Linux movement into less-than-friendly factions.

One proposed solution is to run two operating systems in tandem: Linux plus a separate, real-time kernel. This approach is championed by both Lineo and the creators of RTLinux at Finite State Machine Labs in Socorro, NM. One challenge of such a tandem design is how to get the operating systems to communicate. It also forces developers to work in two different operating environments for every project.

MontaVista supports making Linux real-time by creating "preemption points" within Linux itself. At regular intervals of time, the system will interrupt a given task, check for a real-time request, perform whatever operation is being called for, and then go back to the original task. This method is rather derisively known as "soft" real time in the embedded community. "The problem is, between those preemption points, you can't interrupt," says Rose. Preemption, he argues, "works only if when you miss something every once in a while, it's an annoyance instead of a disaster."

Rose maintains that no amount of tinkering will transform Linux, created as a desktop operating system, into one that works well for embedded computing. "If anyone really wants to work with a real-time operating system, Linux isn't going to be the right choice," he says. "To make it work at all you need to add code, and adding code hurts performance." Rose sees Linux as just one more of a long line of operating systems for general-purpose desktop computers-like Unix and Windows-that have tried and failed to make any significant mark in the embedded world. In his opinion they are all too unwieldy and slow. "You can try to make a truck run like a Ferrari, but in the end it's still a truck," he says.

For the last few years, Linux proponents have been pushing in the opposite direction: trying to beef Linux up, not pare it down. This approach has helped Linux gain ground against mature desktop operating systems like Windows NT. But while loading Linux up with features helps it compete against the likes of Windows NT, embedded systems have cramped memories that put a premium on leanness. Slice Linux too far, though, and you end up, not with Linux, but with pieces of Linux. Even its staunchest defenders say Linux can't be reduced to less than half a megabyte; most think two to three megabytes is more realistic. "The moment you start to pull pieces out, you've broken compatibility with the entire world of Linux software," acknowledges Kevin Morgan, vice president of engineering at MontaVista. "You'll never get Linux in a supersmall memory."