Foreword: This article is the third in LinuxDevices.com's series of reviews, by software developer Jerry Epplin, of Embedded Linux toolkits. In order to gain insight into the use of each toolkit from the developer's perspective, Epplin builds Embedded Linux OS images for three different x86-based EBX… form-factor single-board computers using each toolkit. Each of the toolkits is then evaluated against a common set of criteria which include ease of use, overall toolkit architecture, methods of package management, diversity of platform support, and openness of the source code. In this installment, Epplin takes a close-up look at Red Hat's recently released Embedded Linux Developer Suite (ELDS).

The challenge facing a vendor of an Embedded Linux toolkit can be seen as either simple or complex. The simple approach is to rely heavily on the standard tools and workflow already defined for Linux, perhaps adding a few tools to ease the process for embedded system developers. This is the approach taken by LynuxWorks with their BlueCat product, to be covered later in this article series. The simple model has appeal because it is fairly easy to implement and maintain over time with changes in Linux, but requires documentation of the highest quality so that new Linux users can start producing results quickly. The more complex approach is to redefine the Linux workflow completely, providing GUI tools of the vendor's making to replace standard open source tools. This track is harder to implement and maintain, but if implemented well it might be expected to appeal to those users coming from the world of proprietary RTOS products, who are accustomed to slick user interfaces.

The complex approach is risky because if the GUI layer is implemented incompletely it forces the user to learn both the GUI layer and the underlying Linux layer in order to implement everything needed, making the learning curve longer than if the user only needed to learn the Linux layer. Thus a well implemented simple tool (or, in fact, even a poorly implemented one) is preferable to a poorly implemented complex GUI-based tool. So I find it surprising that so many vendors choose the complex route, given its risks. So far in this series I have covered Lineo's Embedix and MontaVista's Hard Hat Linux, both of which follow the complex path, with varying success. Red Hat's Embedded Linux Developer Suite (ELDS) also follows this tradition.

First impressions

As the best-known Linux company and, following its purchase of Cygnus, a long history of producing and using GNU tools in embedded applications, it is reasonable to expect Red Hat to provide an Embedded Linux toolkit befitting its industry leadership.

Like most other Embedded Linux toolkits, ELDS provides support for the x86, ARM/StrongARM/XScale, MIPS, PowerPC, and SuperH architectures. It requires 1.2 GB of hard disk space on the development host, installing itself at /opt/redhat — giving you no opportunity to install elsewhere. It is very specific in its host distribution requirements; you must use Red Hat Linux, either 7.1 or 7.2, running only under x86. ELDS also requires specific versions of Perl and Python, installing them for you if needed.

The primary market for an Embedded Linux toolkit is new users, since more experienced users can assemble and use the freely available tools without commercial help. So it is especially important that the documentation for such a toolkit be of the highest quality. But the documentation for ELDS is curiously rough, in contrast to Red Hat's usual high quality. I found it to be poorly organized, wordy, repetitive, and clumsily phrased. It is also sometimes unintentionally amusing, as when the author tells us, “The software provides . . . many unsupported tools”, adding parenthetically, “(even though these tools may successfully work)”; as if Red Hat would include tools without some evidence they do something useful. The documentation is full of such poorly worded and often unnecessary statements, producing an overall distracting effect. After a few pages of this one wants to just fire up the software even without first having an adequate understanding of how it works.

Installation is fairly easy; you simply run the Install.sh script on the CD as root. The process mostly installs lots of RPMs onto your system. One of my pet peaves is software packages that provide no uninstallation procedure. ELDS falls into this category; the only advice it provides is to run “rpm -e” on whichever package you wish to remove (ELDS consists of some 55 packages). Uninstallation of all of ELDS could then presumably be done with something like “rpm -qa | grep elds | xargs rpm -e ; rm -rf /opt/redhat”, though Red Hat provides no help for this.

User interface approach

The user interface to ELDS is implemented primarily as a set of Python/Tkinter programs, often poorly integrated. To create a new project you run the GUI-based 'elds' program, which simply prompts for a project name and architecture, creates the project in the directory from which 'elds' was run, and exits. It is not clear how this is an improvement over a command-line interface, perhaps of the form “elds-create projname x86”, especially when an error occurs.

I first ran it without write privileges in the current directory. No error message popped up in the GUI; instead a cryptic “Permission denied” message was sent to the shell from which I ran 'elds', complete with the Python function stack trace. If you aren't paying attention to the shell, or perhaps if you did not run 'elds' from a shell, you would be left staring at the GUI, unaware that something went wrong, and wondering how long it will take to complete. Once I got my permissions right, everything progressed correctly, taking about a minute to complete as it copied the kernel and root file system to the project directory — again, sending progress reports only to the shell.

Once this process is completed, 'elds' does helpfully pop up a window indicating success — and instructing the user to run a series of command-line programs to continue. Unless you've got a better short-term memory than I you'll have to keep this popup window available as you type in the commands, one of which contains both a dash and an underscore. Or you can consult the manual, which contains an extended justification for the requirement that portions of this process be run as root, and descriptions of the C wrappers and shell scripts involved — the reader is overwhelmed with the unnecessary information overload.

In general, I found the experience of this chaotic hybrid GUI/command line user interface somewhat bemusing. I suspect a new Linux user, struggling to become accustomed to the environment, would not find the experience enjoyable.

• Part 1: Toolkit strategies
  
• Part 2: Configuring the system
  
• Part 3: Building target images for three SBCs
  
• Part 4: Overall assessment

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.