Embedding Linux in a Commercial Product

Embedded Linux does have its drawbacks. For one, it can be a memory hog, although it's not much worse than some of its commercial competitors. Part of this can be whittled down by removing unused features, but this may take more time than it is worth and may induce some ugly bugs if not done carefully.

Most Linux applications are addicted to virtual memory, which is of dubious value in many embedded systems, so don't assume an embedded system with no disk will run any Linux application.

The kernel-level debug tools are not all that great, particularly at the lower levels. kgdb can have hard landings fairly easily, and you just have to reboot. Unfortunately, print statements get used more than we'd like.

The worst problem for me, however, is a psychological one. Linux is extremely flexible. Embedded systems are generally not flexible; rather, they are highly engineered to perform their intended function optimally. There is a tendency to preserve the flexibility, keep the general purpose capabilities and make as few changes as possible. These are noble goals, but they come at the expense of sharply tuning the system for the specific job. Keeping this flexibility can result in extra work and carrying extra software baggage around, and sometimes involves tradeoffs which degrade performance. One example that comes up repeatedly is configuration. Consider configuring the IP address on a network interface, which is usually done by running the ifconfig program from a startup script. This is a 28K program that could be replaced with a few lines of code to initialize the appropriate structures, using data from a configuration file. Nevertheless, while this is a reasonable thing to do, it still “hurts” because it is contorting the software in ways it was never meant to be used.

Using Linux for an embedded system is possible and has been done. It works. It is reliable. The development costs are in line with the alternatives.

Glossary