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? This article presents 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 8 MB of RAM. It should be noted, however, that it is recognised 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 a developer not 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 organisations that provide sophisticated Linux distributions, support and development help.
Our goal is to provide a systematic means for developers to characterise the offerings they see. The Taxonomy is intended to be able to categorise any and all products or services from which an embedded Linux developer may benefit. The Taxonomy is also convenient for suppliers to characterise 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.
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 categorising 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 16 MB or less. This means that our discussion will not be as useful for someone building a 256-processor, 16 GB 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 do not mean, for example, a system that may happen to share an API with Linux. When we say kernel we mean that software that is included in a kernel release tar file.
The issue of whether a supplier is supplying a kernel unmodified from 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 behaviour. 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 nonstandard version of a kernel using the category SoftwarerSpecial DistributionrPatched Kernel (see Figure 2).
Embedded Linux is the use of Linux as the operating system in an embedded system. There are various references for why this is a valuable notion to consider. See www.linuxdevices.com
Why can't a developer just use a standard desktop or server distribution? The definition of embedded includes the characteristic that our target system has more limited resources than a standard desktop or server system. If your target does not then you may well be able to use a standard distribution as long as it can satisfy your time constraints. Since there are lots of overlaps between the needs of desktop or server applications developers and embedded system developers, the Taxonomy does include some categories that would interest other developers, too. The Taxonomy, naturally, however, includes only categories specially designed to classify embedded Linux system offerings. In Part II we will discuss these categories further and take a tour of the Taxonomy.
Authors: Kevin Dankwardt is Founder and President of K Computing, a Silicon Valley training and consulting firm. Matt Reilly has worked for K Computing for three years administering Linux servers and teaching Unix and Linux classes.
Article supplied by Electronic Products Design. For further information about embedded development contact Jaap Willemse, Electronic Products Design, (012) 665 9700. This article was originally published in Embedded Linux Journal, Winter 2000, ( embedded.linuxjournal.cm) published by SSC, ( www.ssc.com) and reprinted with permission.
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version