A Taxonomy of Resources for Embedded Linux Developers

Think you need a program to get into embedded Linux? Well, here it is.

So you want to run Linux on the new-fangled, network ready, Linux based, ``all homes will want one'', revolutionary appliance you just developed? Congratulations. Now what are you going to do for a version of Linux, device drivers, technical information, or tools? We present a hierarchical system, a taxonomy that describes the various kinds of products, services, or information that an embedded Linux developer (should we call them ELDers?) may need, or at least want. Our system is in the tradition of the Linnean system. We classify the flora and fauna that inhabit the embedded Linux world. Whether a particular item is flora or fauna we leave up to the reader.

We describe characteristics of the offerings that are to be used on the host or target systems. Embedded system developers may perform their development work on a system quite different from the system that will be deployed running their software. For example, a developer may be using a Sun Microsystems workstation running Solaris and cross compiling for a small device with a StrongArm processor and only 8MB of RAM. It should be noted, however, that it is recognized as a great benefit that developers can often use a Linux-based development environment coupled with a Linux-based target.

We use the term host to mean the computer system that the developer uses to interact with the development tools and the term target for the embedded system that will run the software that is being developed. The embedded Linux offerings supply development tools for the host system and drivers, special applications, or custom kernels for use on the target. When evaluating a supplier one needs to consider both their host and target support.

What We Will Cover

This article has the following parts:

  • Use and goals of the Taxonomy

  • Who should use the Taxonomy?

  • Defining embedded Linux system

  • Why can't a developer use a desktop or server distribution?

  • An overview of the Taxonomy

  • Using the Taxonomy--an example vendor

  • Conclusion

Use and Goals of the Taxonomy

The Taxonomy has been derived from existing products and services. There exists at least one product or service that fits into each category.

How a particular supplier's offerings cover of the needs of a developer can be used to determine a good choice of suppliers. The Taxonomy can help a developer to write a checklist, in some sense, of what is required. It is to be expected that no one supplier will supply all of the needed information, hardware, software, etc. Some suppliers are volunteers that provide, say, a single device driver, while others are commercial organizations that provide sophisticated Linux distributions, support and development help.

Our goal is to provide a systematic means for developers to characterize the offerings they see. The Taxonomy is intended to be able to categorize any and all products or services from which an embedded Linux developer may benefit. The Taxonomy is also convenient for suppliers to characterize their offerings. Instead of saying, ``we use a standard kernel``, or ``using standard Linux'', or some other undefined phrase a supplier can now say ``we do not patch the kernel''. In this way the Taxonomy provides a common language for developers and suppliers with which to speak to each other.

The Taxonomy does not provide a means to evaluate the quality of a supplier's offerings, merely that the supplier has something available. The top two levels of the Taxonomy are shown in Figure 1.

Figure1. Top Two Levels of the Taxonomy

Who Should Use the Taxonomy?

If you are an embedded Linux developer then you may find this classification system helpful in understanding the landscape. In addition, we provide real examples of the kinds of resources that are available. Vendors will also benefit by the using this established means of categorizing their offerings instead of having to make up their own terminology.

Defining ``Embedded Linux System''

By embedded system we mean a computer system that functions inside of a device whose main function is not that of being a computing system. Examples include cellular telephones, PDAs and microwave ovens. We will also concentrate on devices with relatively limited resources such as no hard disk, or RAM of about 16MB or less. This means that our discussion won't be as useful for someone building a 256-processor, 16GB telescope directing system for the top of Mount Haleakala to view man-made satellites in orbit.

By Linux, we mean a system whose kernel is derived from a release of the Linux kernel. The version should share a great deal of the source code with a released version. We don't mean, for example, a system that may happen to share an API with Linux. When we say kernel we mean that software that's included in a kernel release tar file.

The issue of whether a supplier is supplying a kernel unmodified from http://www.kernel.org/ or one that they patched can be important. Some embedded Linux vendors have made significant changes in the kernels that they distribute. These changes can be essential to a target application. For example, the changes may provide the required scheduling behavior. On the other hand, these changes in the way the kernel behaves can provide a significant dependency of the application on the modifications. Changes in the kernel result in divergent paths or fragments. This fragmentation is reminiscent of the differences that resulted in somewhat incompatible versions of UNIX such as Solaris, HP-UX and Irix.

We prefer that suppliers make clear what changes they have made. A patch file is a standard way of documenting changes. In addition, clear documentation is valuable. If a vendor changes the kernel then we prefer that they give their version a name, for example, Purple Chicken Linux 1.1. If a vendor does not make any changes then merely saying the Linux version number is appropriate, say Linux 2.2.14. Similarly, if a vendor changes a tool or application then its appropriate to distinguish that, say, Purple Chicken gdb. If the vendor does not change the tool then merely calling it ``gdb'' is appropriate. It has become confusing since some vendors are calling everything in their distribution by their distribution name.

Our classification scheme, for example, allows one to note that a supplier has a non-standard version of a kernel using the category Software®Special Distribution®Patched Kernel (see Figure 2).