Managing a project

In the Embedix model, a build is a project, consisting of a directory tree rooted at a user-settable location. Basic project settings are included in a project file; for example, the settings for a test project running on my laptop was named laptop.epj. This file contains basic information such as the name and location of the project, as well as user preferences.

The actual build is controlled by state files, ending with .sdf. The state file for the entire project being defined is in the build/projectstate subdirectory of the project, and is named ” < projname > .ess”. These files have an XML-like syntax; though inexplicably Lineo failed to make the syntax fully well-formed XML, which would have made it possible to manipulate the files using standard XML tools. SDF files determine which components are included in the system being constructed.

Here's a simple example . . .

The components are defined in a tree structure — in this case we are defining the values for the /Programming/Debugger part of the dependency tree. We're including gdbserver and startkgdb in the target build, which excluding metrotrk. Target Wizard normally handles the creation, maintenance, and manipulation of SDF files, but the simple and obvious structure of the files makes it easy for developers to write their own tools to meet any special needs they have; though for Lineo to have made them well-formed XML would have made it still easier. Also noteworthy is that an SDF file can define a subset of the dependencies in a target build (as in the example above); it need not define the entire system. This allows you to save subtrees of a project and reuse them in other projects in very flexible ways. Target Wizard fully supports this subsetting. So, for example, you might have a system that you want to prototype on several boards, each having a different Ethernet driver. With state file subsetting, you could construct a project; then cut and paste those portions concerning the Ethernet driver to support the different target boards.

To help minimize the size of a target system, Lineo provides a proprietary tool called Lipo. It analyzes the target build, finding any unused symbols within included shared libraries. Upon finding any such unused symbols, Lipo eliminates them from the build. The assumption is that the system as Lipo knows it at build time constitutes the entire runtime system; i.e., that no programs will be added by the end user. This is of course a valid assumption for most embedded systems; but fails for systems such as PDAs, where users may add their own applications; thus Lipo should be used advisedly. Lipo can be compared to, for example, the “static build” option of the Trolltech Qt Palmtop Environment. But rather than simply throwing away symbols within shared libraries, QPE statically links the entire system, since dynamic linking adds nothing to a system in which the entire application environment is known in advance.

Scrunching the C library

One of the biggest challenges in minimizing the size of an embedded Linux system is the GNU C Library. As anyone who has looked at the glibc source code knows, it has intricate interconnections — a call to, say, sprintf() results in calls to dozens of functions in many different files in glibc; this makes it hard to minimize the size of glibc either manually or automatically. I asked Tim Bird, Senior VP of Research at Lineo, about their efforts to minimize the footprint of the C library. He reports, “With LIPO, we commonly get somewhere between 200K to 600K reductions in the size of glibc.” The reduction is limited because of the interconnectedness of glibc, but he expects that future work on modularizing the library could result in more reductions when using Lipo.

Tim Bird considers minimizing the C library to be of great importance for minimizing the embedded Linux footprint, as it is the largest component they ship; larger than the kernel. As a result, they have taken a second simultaneous approach to the problem; namely, creating an alternative C library from scratch. Tim Bird expects this library, called uClibc, to be appropriate for some applications, but not to replace glibc for higher-end products. uClibc is not the only attempt to provide an alternative to glibc for embedded applications (see, for example, dietlibc or Red Hat's Newlib), though it is one of the most active currently. It will be interesting to watch the progress of this important work.

Deploying the target build

Embedix helpfully provides seven ways to deploy a target build. For development, you might choose the “self-hosting ramdisk filesystem”, which allows you to boot a target build on your host computer. You run LILO, then choose the Embedix build from the LILO prompt upon rebooting. The target is built as a ramdisk, so your desktop must have sufficient memory to hold the entire system. A representative build on my computer was about 5 MB, so this should not normally be a problem. Another deployment option is building a set of floppy disks for installation on the target. If your target has a floppy drive attached (or you can attach one temporarily), Embedix can deploy to the target using a set of bootable floppies, which copy the image to a filesystem on the target when booted. The system can be configured to operate as a ramdisk-based system or can be deployed to operate as a normal (disk-based) filesystem on the target.

Similarly, if your target has a CDROM drive you can deploy to a CD that acts as an installation disk, copying the system to the target's filesystem when the CD is booted. Or, to build a system to operate like the NIC, you can build a system that boots from and runs from a CD, not requiring any hard drive or flash drive. I encountered a failure when attempting to use this option with Embedix SDK 2.0; Lineo reports that it is a known problem addressed in a service pack to be released soon.

Finally, you can simply create a directory tree on your local disk; this might be useful for making sure your files will go to the right places on the target. You can also make a filesystem to chroot into — this allows you to run your application as if you were on the target.

Target Wizard is robust and flexible enough to meet the needs of most systems, but Lineo is to be commended for making the build definition process transparent enough to be easily customized. The integration of the kernel configuration and build process into the dependency resolution is a welcome feature.

• Part 1: First impressions
  
• Part 2: Managing a project
  
• Part 3: Thoughts on the kernel configuration process
  
• Part 4: Other Embedix components and features
  
• Part 5: Lineo's real-time Linux option
  
• Part 6: Taking Embedix for a spin

 
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.