Using Linux while avoiding costs

The defining characteristic of Linux is its rapidly changing code base. This means that along with Linux's rapidly growing popularity comes a broad set of choices and varying degrees of engineering effort to make the "free" elements work together.

So how does one use the formidable potential of embedded Linux while avoiding choices that can lead to hidden costs? In terms of general performance, Linux is blazingly fast. Its networking facilities are becoming the de facto standard for real-time OSes. Embedded developers can leverage Linux's initial design considerations, whose roots lie in the "slow" 386 architecture. This architecture drove a monolithic design of the OS due to its very efficient use of the microprocessor hardware, which plays well with processor choices used in most embedded systems.

Developers must decide whether a system requires hard or soft real-time, or no real-time at all. If real-time determinism is not required, the off-the-shelf, or stock Linux, kernel provides a baseline choice. Stock Linux version 2.4 is not reentrant, meaning that with respect to real-time, if a task is in the kernel then it must exit the kernel before a "reschedule" of the processor can happen. This hinders the real-time responsiveness of the stoc k Linux kernel in v2.4 but, starting with an interim release of the v2.5 beta Linux kernel and beyond, the preemption and low-latency patches will be incorporated into the standard kernel, making stock Linux a formidable soft real-time choice.

For hard real-time performance within a Linux OS, designers can look to the hybrid kernel, or RTLinux approach, which enables a real-time kernel to run under Linux. This approach is implemented through licensable technology developed by FSM Labs, which holds the U.S. patent for RTLinux. With a hybrid kernel, nonreal-time tasks run on top of Linux while hard real-time tasks execute in the real-time kernel. In this model, the responsiveness of Linux is isolated from the real-time performance.

The other option for hard real-time performance is through Linux kernel replacement. This can be achieved through ABI compatibility with a true hard real-time operating system, and allows embedded developers to have the best of both worlds. They can leverage the numb er of available Linux applications programs (browsers and tools, for example) and also leverage the inherent hard-real-time capabilities of the RTOS.

The primary question for any developer is determining the appropriate Linux distribution that will provide all the necessary features. From the simplest level, there are essentially three choices. Linux was designed originally for desktop workstations. Embedded designers can always use a standard PC-focused distribution, but unless the hardware resembles a workstation, this is likely not the best choice. Boot requirements, installation requirements and architecture requirements are all considerations that will need to be closely examined.

The next choice is to create a unique Linux distribution, which gives designers the freedom and flexibility to design a Linux OS specifically for their application, from the kernel level up. Designers decide on required features and choose the most appropriate kernel (www.kernel.org) or distribution. One prob lem with this approach is that the Linux code base is highly dynamic and the required packages for your embedded device, if not integrated to the kernel revision, will require either forward- or back-porting to your kernel revision.

A means for getting around these difficulties has emerged with the commercial off-the-shelf (COTS) embedded Linux distributions. An embedded distribution will include the required embedding tools and full life-cycle support, and will be aimed at popular reference boards with drivers and features preintegrated. These platforms include a cross-development tool set and a common code base that will be common across all supported platforms-MIPS, ARM, PPC, Xscale, X86 and the like. This code base makes the OS supportable for the long term by the embedded Linux company.

Minimizing manpower

Using COTS embedded Linux can minimize many of the costs of a Linux implementation. To create and support its own Linux distribution a company could have up to six eng ineers working solely on Linux porting and support, including back-porting patches and kernel features, carrying them forward to later releases, providing internal support to application teams and so on. These processes can work out to burdened-manpower costs of $900,000 annually, in addition to having to acquire commercial-grade development and testing tools. Working with a COTS embedded Linux distribution and consultants from a Linux company can cut these costs. They make it easy for an organization to outsource core Linux expertise and focus on individual product differentiation.

Other costs to consider: Linux is licensed according to the GNU GPL, which has a strict set of rules for use. There are many "interpretations" of this license, so evaluate the license and the terms of its use. Not all utilities and applications in an off-the-shelf Linux distribution are licensed under the GPL. These may require royalties, or separate licensing for commercial use.

Other issues include costs relate d to intellectual property. Any nonisolatable IP may become encompassed by GPL upon product shipment, and the source code would need to be made available upon request. Also, no indemnification is built into GPL, which could open the door to more costs and risks. An IP attorney should be consulted when determining the level of exposure the company is willing to accept.

http://www.eet.com/