As budgets decrease, product life cycles shorten, and more features are packed into electronic devices, developers are feeling the pressure to deliver advanced software. While Linux and open source are often the right choices for embedded development, they cannot work magic. Some costs are still associated with selecting open source development tools. In deciding which tools to use, developers must consider if they are spending their time on that which is truly innovative and differentiating or on busywork such as integration and support.

Tool selection can help or hinder developers’ efforts to gain control of a project. The litmus test for truly valuable tools is whether or not they assist developers to enable the right features within a product’s short life cycle.

One area of embedded Linux development subjected to this loss of control is the process of building the often complex file systems Linux depends upon. Platform developers need to integrate and install dozens and sometimes hundreds of separate software components, but creating a target file system by hand is time-consuming, difficult, and complex. Without the right tools, this process can be prone to error. That time and effort can be better spent on developing features that differentiate products from the competition. Among the most difficult and, in a sense, least rewarding activities is Linux file system configuration.

Traditional Linux development

The first incarnations of Linux were developed in an environment where the target was either on the host itself or a comparable machine. Because of this, accompanying tools traditionally have been tailored to a host development environment. Fundamentally, it is easier for developers to develop for a machine similar to the machine they are developing on. As the target environment draws farther away from the host environment, developers face greater challenges.

Developing for the host or similar environment does not require much extra work. In fact, some embedded systems are so similar to a PC that developers can run the actual Linux distribution of their choice, such as SuSe or Fedora. But developing for one of the different processor architectures in the market today can be a challenge.

Embedded Linux development and cross-development

Environments become more complex when resources are constrained and the target processor is running one of the many non-x86 processors available. In this environment, it is more productive to develop on a host machine with many resources and then cross-compile to develop a binary for the particular processor architecture.

Because of its modular design, Linux runs efficiently on small devices. Developers can select the features they want to implement and prune the ones they don’t need. True finesse is required to accomplish this task and fine-tune the features and user interface for a particular device.

But just because it is modular doesn’t mean there is a clear path to success. Developers must consider two approaches: follow a package-based installation, which leverages the majority of Linux distributions available, or integrate packages into a build system environment. One issue with a build system is that it is incongruent to the way Linux is distributed – generally, as packages like .deb or .rpm. Another challenge is the learning curve necessitated by any particular build system. The following discussion will present package managers and explain how they can help or hurt developers’ ability to build embedded Linux file systems.

Choosing an Embedded Linux file system manager

Ian Murdock, founder of the Debian GNU/Linux distribution, describes package management as “the single biggest advancement Linux has brought to the industry.” He thinks package management blurs the boundaries between Operating Systems (OSs) and applications, making it “easier to push new innovations … into the marketplace … and evolve the OS.”

The tools available for building embedded Linux file systems become more useful in cross-platform and resource-constrained environments. It is important for developers to ask a few questions before selecting a particular tool or Integrated Development Environment (IDE). Consider: Where are you getting your Linux source, and how is it wrapped up for delivery? What are you using the file system for, and how can it be optimized for a particular target? The package installer that developers choose can make the difference between an optimized file system and a poor excuse for an embedded device.

A common approach to managing an embedded Linux file system is using a package manager like RPM or dpkg for installing and removing a nonroot directory, fakeroot for a sneaky way of doing chroot that doesn’t require root permission, or development with a virtual target like the Linux QEMU processor emulator or Virtutech’s Simics Virtual Platform. Each of these different options has pros and cons that may be remedied by an alternative solution: a platform image builder.

Package manager

The reigning champion of file system management is the RPM package manager. RPM is useful because it is standard and available on most Linux systems. Like others of its ilk, RPM has built-in capability to install to a directory that is not the system root, which is advantageous because smart developers don’t want the ability to accidentally destroy their host file system. But RPM doesn’t solve package dependencies; it merely determines whether or not dependencies are met. It requires that developers already know the dependencies and therefore won’t go checking the various packages to determine which ones need to be resolved to build the file system.

To resolve dependencies, developers must add another tool such as Yellowdog Updater (yum) or Advanced Packaging Tool (apt). As a library of C++ functions, apt was created to efficiently install packages while handling dependencies and taking care of configuration files during upgrades. However, apt and yum are limited to the command line. If developers are new to Linux or these tools in particular, they may face a relatively steep learning curve. Additionally, all information is textual and often difficult to navigate relative to graphical file system managers.

Faking out root

Linux can set permissions appropriately to protect the system from malicious intent, ignorance, or forgetfulness associated with modifying or deleting files. Linux has a base root directory that houses all subdirectories. This base root, often called “/” (pronounced slash), is protected from Linux system users. Administrators limit access to “/” and provide each user with a modifiable home subdirectory underneath it. This enables users to access the system and accomplish their tasks with the appropriate rights and abilities.

However, some file system creation operations require root privilege. Without root privilege, developers can’t create a file owned by another user, create a device node, or commit a change root operation. These restrictions limit the ability to configure a file system.

One option is to use a tool like fakeroot, which can create a virtual “/” file system tree within a directory on a user’s host system. It provides a fake “/” environment by redefining standard functions within the host system libraries. In this way it changes the utilities that reference files and captures privileged information about files without requiring root privilege to create them. Additionally, it can be used with standard utilities without requiring special tooling. As with RPM, fakeroot does not solve dependencies, leaving this arduous task up to the developer.

And here’s an additional challenge involved with both RPM and fakeroot: Developers may want to execute code within the target directory, and if that code is for a different architecture than the host, it simply won’t run.

Virtual development

A third alternative to building a file system is using a virtual environment like QEMU, Simics, or VMware Workstation. This solves the challenge that both package managers and fakeroot tools face – not being able to run code on a host with a different architecture than the target. A virtual environment also provides the ability to develop for a virtual target using all the resources available on the host, such as memory, storage, and a fast processor, enjoying many of the advantages of self-hosted development on a PC.

Using a virtual environment is often faster than developing on the target itself, but it can add complexity, slowing processor power relative to cross-development.

Platform image builder

 

 

As outlined in the beginning of this article, platform developers need to integrate and install dozens if not hundreds of separate software components, but creating a target file system by hand is time-consuming, difficult, and complex. Once the file system has been created, it must be converted into a target image (see sidebar). More advanced tools can simplify the task of assembling, tuning, and creating an image of the file system.

Platform image builder accomplishes this by providing a visual map of the system for selecting Linux target packages, integrating custom packages and kernels, dynamically determining file system size, automatically resolving dependencies and conflicts, and generating file systems in several standard formats.

Platform image builder is useful for trimming components from a final image, whether they are individual files or whole hierarchies (for example, documentation and sample configuration files). Having the ability to visibly sort packages into groups like documentation, fonts, graphics, or interpreters can provide developers with quick access to and faster elimination of unnecessary packages (see Figure 1).

 

 

This ability also enables users to drill down and sort through files and directories via a tree hierarchy. To remove a file, simply uncheck the adjacent box (Figure 2). In addition to removing individual files, developers may choose to mark entire required supporting packages as “phantom.” Such packages are necessary for building other packages but not for the final build, and are therefore not included at runtime.

 

 

While setting up a platform image project (.pib), developers can include and integrate custom packages and kernels. This flexibility provides the competitive differentiation and control embedded developers demand in such a fast-paced market.

Platform image builder gives a number of options affecting the size of the image file. It does this by:

1. Optimizing library footprints and reducing the size of some shared libraries
2. Pre-linking executable files, making start-up times faster
3. Removing debugging symbols from final binaries, making them both smaller and faster

These measures are designed not only to reduce the size of the image, but also to improve performance.

Platform image builder uses the dependency information included in RPM packages to automatically include supporting packages as necessary (Figure 3). This is consistent with the way Linux is generally distributed and takes away the mundane tasks of manually working out dependencies. However, when making package selections, it is possible to select packages that conflict with each other. Since this results in errors and prevents projects from building successfully, developers must resolve conflicts before creating images. Platform image builder helps by flagging and listing all conflicts as errors, making it easy to review and change them until all conflicts are removed.

 

 

Finally, with a file system management tool like platform image builder, platform developers can produce common file formats, including ext2, JFFS2, cpio, CRAMFS, and ext3. Depending on the format, different options are available to configure the image and set mount points.

In contrast to the previously mentioned methods of creating and managing file systems for embedded Linux development, platform image builder has a graphical user interface that does not require an emulated environment and therefore doesn’t use as many resources relative to a virtual machine. Platform image builder turns file systems into an image without the complexity and slower processing power, giving developers the productivity required for embedded Linux cross-development projects.

The tools litmus test

Embedded Linux developers can obtain more control over building complex file systems with a tool like platform image builder, which makes assembling, tuning, and creating a file system image easier to accomplish. This enables developers to spend time developing features that differentiate products from the competition. Remember, the litmus test for truly valuable tools is whether or not they assist developers to enable more of the right features within a product’s short life cycle.

Troy Kitch is senior product manager of the developer tools team at MontaVista Software, based in Santa Clara, California. Troy has spent more than a decade in the development and security software industries, focused on developer productivity, data storage, and disaster recovery. At MontaVista, Troy is responsible for helping organizations get the most out of open source by managing the MontaVista DevRocket integrated development environment. Troy has a BS in Agribusiness from Cal Poly, San Luis Obispo.

Joe Green is manager of the developer tools team at MontaVista Software. Joe has been working with Linux and UNIX systems at companies such as MontaVista Software, IBM, and SGI for 20 years and has been happily using Linux since version 0.12. He is particularly fond of kernel and graphics code as well as real-time and embedded systems. He has a BSEE from the University of Miami.

MontaVista Software
408-572-8000
[email protected]
www.mvista.com