Is embedded Linux the right answer?

Embedded systems are very different from the network servers where Linux grew up, and they have different requirements. Linux was never designed for the small memory footprint and real-time, low-power requirements of embedded systems. It also lacks support and tools, making development costly. And although Linux is open-source, it is not free and entails hidden associated costs.

The GNU public license under which Linux resides raises intellectual-property concerns for device manufacturers. Linux is just an OS, and increasingly complex embedded systems require a true platform. Most important, Linux will not lower costs, reduce risks or save money in getting products to market.

Embedd ed devices have critical requirements with respect to real-time operation, footprint, speed and other parameters. Linux is not a real-time operating system, and to make it work in this environment, device manufacturers need to significantly customize it. Often, manufacturers create a hybrid form of open-source software or modify the Linux kernel and strip out the essentials to improve run-time. This must then be further customized for the specific application hardware, form factor and capabilities. Now "standard" Linux has morphed into a customer-specific creation that no one but the developer can support. The result: a fragmented embedded-Linux platform and engineers enmeshed in integration.

Without a single agreed-upon platform, Linux faces other development challenges-namely, a lack of tools and support. Because of the market fragmentation, there is a shortage of cross-compilers, debuggers and real-time analysis tools. Developing, testing and debugging production-quality code is challenging enough -even with the right tools. Without them, developers have to cobble together solutions and the development cycle slows.

The tools shortage is exacer-bated by the shortage of embedded-Linux support. Because embedded devices have critical requirements with respect to footprint, capabilities, power profile and speed, Linux must be modified to work in this environment, especially when devices are designed with a high level of integration among hardware, software and firmware.

Without a single platform, the larger Linux community cannot provide support.

There are potentially thousands of tweaked versions of Linux that no one outside a device maker's software team has ever worked on. So, the support burden falls back on the device companies themselves, resulting in engineers spending valuable time on OS support, integration and testing rather than on product innovation and time-to-market.

Corporate customers have adopted Linux because there is no cost to acquire it-it is easy to d ownload from the Internet-and one can use it without paying for it. These two qualities have led people to call open-source software "free."

Although one may obtain Linux for nothing, everything you do with it after that has a cost, in both time and money. Most costs arise after a company actually licenses the software. These include integration, These costs are substantial and a reality with open-source software. In fact, using uncontrolled, unsupported open-source software can raise such costs, not lower them.

Beyond the real costs of open-source software, there are significant hidden costs. The license for most contemporary open-source software is known as a GNU public license (GPL) that requires those using the Linux kernel to run their software to make that software open and available. A key passage in the GPL reads: "You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this license."

This language creates an intellectual-property problem for embedded-device manufacturers. A reasonable interpretation is that software contained in a device, if that device "in part contains" any GPL-licensed code, must be "licensed as a whole, at no charge ... under the terms of this license." This is crucial for device makers, which license all the software in their systems as one bundle, since it is all "invisible" inside the device they sell. If part of the software is covered by the GPL, then all the software may be subject to the GPL and must be given to the open-source community.

Licensing issues

GPL affects companies because of the licensing language and the real impact on product development due to that language. One example of how GPL impacts product development was cited earlier this year in the Financial Times. A developer at a worldwide leader in visual-processing solutions used a portion of code fr om a freely available video driver; however, this developer failed to realize the code was licensed under the GPL. Because this company did not want to release the source code for its commercial software, it was forced to develop a new driver that did not contain GPL, which incurred substantial costs and resulted in product delays.

GPL licensing can lead to unanticipated liability. Even the smallest amount of code that violates the GPL can delay release of a product, or worse. The bottom line: There may be real risk, and there is cost - in legal review, engineers modifying their methodology to avoid running afoul of an untested license and delays caused by complications.

Does "free" mean faster time-to-market? Modifying Linux for embedded environments requires hours of development, often slowing time-to-market. Manufacturers need solutions that accelerate development, have a clear technology road map and come from a supplier that offers ongoing support.

Those of us who work in the e mbedded-software world can sometimes get wound up in thinking about operating systems. The reality, though, is that the end user buys a device based on cost, features and reliability, and doesn't care about OSes. Organizations, on the other hand, need to care a lot about how they build the embedded software that goes into those devices, because it is so expensive to develop and so crucial to the product. The best way to create that software is to work at as high a level as possible, since by far the largest cost is in integration and test.

Linux is an OS, not a platform. The bar needs to be raised. We need to think at a platform level, not at an OS level, and certainly not an OS that each device maker needs to integrate, modify and support internally. If the OS can't be adequately customized, it can result in increased product costs -if this affects time-to-market, the lost revenue and profit will dwarf anything saved by using "free" software.

Linux may evolve to offer fundamental business b enefits. But for now and the foreseeable future, its disadvantages clearly outweigh its benefits.

See related chart

http://www.eet.com/