Other Embedix components and features

Other components of Embedix are more in keeping with an open source philosophy. As one might expect, Embedix uses GCC as its compiler. Prebuilt binaries are provided for the supported target architectures. Also, GDB is used for debugging, and is used without significant modifications. For application debugging, gdbserver is provided as the target agent, while either the command line oriented gdb or the graphical ddd is provided for the cross-debugging host. As usual, Lineo provides good documentation for getting started debugging in Embedix; they also provide the more complete GNU documents for greater detail. Similarly, Embedix supports kernel debugging via kgdb. All of this is well within the mainstream of Linux debugging, and works well.

Embedix makes default target configuration decisions that are quite sensible, and will be appropriate for almost all embedded systems. LILO is used for bootstrapping x86 targets. More compact options exist, but it would seldom be worth giving up the flexibility of the standard bootloader to save the small amount of space that LILO uses. On the other hand, Lineo chose to use a greatly simplified version of the arcane System V init system that has been the bane of Linux newbies for many years. But it is sufficiently similar to SysVinit that experienced users will have no trouble finding their way around the default Embedix init system. Only one runlevel is supported — a reasonable limitation since runlevels seldom have a place in embedded systems. /sbin/init (which is really just a link to BusyBox, discussed later) runs the script /etc/rc.d/rcS, which in turn runs all of the scripts in /etc/rc.d/init.d in numeric sequence. Finally, /etc/rd.d/rc.local is run. No special support is provided for daemon shutdown scripts (as with the /etc/rc.d/rc?.d/K* symbolic links in SysVinit); this may make sense since most embedded systems cannot rely on being “properly” shut down in the sense that a desktop computer is shut down.

As one may expect, Embedix uses BusyBox extensively, as this package (originally by Bruce Perens) is now maintained by Lineo. For those unfamiliar with BusyBox, it is a single executable file that takes the place of a myriad of unrelated Linux utilities. Everything from adjtime to zcat is implemented in a single executable, and soft links to that executable are placed where applications expect them in the root filesystem. When, say, /bin/cat is invoked, BusyBox is run, determines how it is supposed to behave (by looking at argv[0]), and executes the portion of its code that simulates the standard UNIX 'cat' utility. The BusyBox executable is significantly smaller than the sum of the sizes of the standard utilities because it saves the overhead that every Linux executable must have, and because BusyBox omits some of the less often used options of many of the utilities. BusyBox is also quite configurable — at build time one can leave out functions if the application does not need them or if you would rather use the full Linux version of a specific utility.

Adding your own apps

Custom applications can be added in at least two ways. The most elegant way is to create a custom Target Wizard package, which is then integrated into your Target Wizard project along with those packages provided by Lineo. This process consists of creating custom LBC (build control files similar to RPM specfiles) and ECD files. ECD files contain the information Target Wizard needs to integrate the component into its framework — you specify the symbols that the component depends upon (shared libraries, for example) and the symbols that it provides (in case other components may depend on your custom application). A few other details are also provided in the ECD file; for example help text for TW to display, and a list of files needed at runtime. Finally, you provide the system source code, which can be in the form of an SRPM file. This entire process, including the formats of the LBC and ECD files, is well documented.

Integrating your application into Target Wizard may be overkill in some cases, so Embedix provides a direct way to merge your files into the target build. You simply put your files into a directory tree called 'merge', and TW includes them in the build. Of course, no automatic dependency resolution is performed, but for many applications the benefits of TW integration may not outweigh the bother of creating and maintaining the configuration files.

Supported platforms

Of course, the software development environment provided by Embedix is of no use if the system does not support your target platform. Currently Embedix provides builds for ARM, StrongARM, MIPS, SuperH, x86, and PowerPC processors.

Whether the board you are using is supported will depend primarily on the availability of drivers for its peripherals. As board support is an area full of pitfalls, you should ask the toolkit vendors about your specific platform before choosing.

What license was that?

As reported earlier, Lineo plans to release a suite of tools, called the Embedix GPL Compliance Toolset, to help in determining the licensing of the components of a user's build.

Given the mixture of proprietary and open source licenses of the components provided by Embedix, this is an important enhancement to prevent users from releasing systems in violation of one or more component licenses. Some components have Lineo's proprietary license, necessitating in some cases royalty payments or other arrangements. Of course, most components of Embedix are licensed under the GPL, requiring (among other things) source code to be made available.

The licensing tools, which are based on Python, will be implemented as wizards within Target Wizard, having access to the TW configuration data, build information and logs, and binary target images. The tools will be able to analyze your system on any of these levels; reporting license information on the TW options you choose or on the resulting binary target image. Finally, there will be a “software interview wizard”, which, Tim Bird reports, “asks the developer about their code, coding practices, etc., and points out potential areas of risk with respect to their use of open source licenses.”

The tools will be available later this month (September 2001). For now, developers must simply be aware of the licenses governing the components they build into their systems.

• 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.