package.
BusyBox operational issues are considered, including how it is used in an embedded system. We examine the BusyBox initialization sequence and explain how this departs from the standard System V initialization. In this section, we also present an example initialization script. After seeing the steps for installing BusyBox on a target system, you will learn about some of the BusyBox commands and their limitations.
11.1. Introduction to BusyBox
BusyBox has gained tremendous popularity in the embedded Linux community. It is remarkably easy to configure, compile, and use, and it has the potential to significantly reduce the overall system resources required to support a wide collection of common Linux utilities. BusyBox provides compact replacements for many traditional full-blown utilities found on most desktop and embedded Linux distributions. Examples include the file utilities such as ls, cat, cp, dir, head, and tail; general utilities such as dmesg, kill, halt, fdisk, mount, umount; and many more. BusyBox also provides support for more complex operations, such as ifconfig, netstat, route, and other network utilities.
BusyBox is modular and highly configurable, and can be tailored to suit your particular requirements. The package includes a configuration utility similar to that used to configure the Linux kernel and will, therefore, seem quite familiar.
The commands in BusyBox are generally simpler implementations than their full-blown counterparts. In some cases, only a subset of the usual command line options is supported. In practice, however, you will find that the BusyBox subset of command functionality is more than sufficient for most general embedded requirements.
11.1.1. BusyBox is Easy
If you are able to configure and build the Linux kernel, you will find BusyBox very straightforward to configure, build, and install. The steps are similar:
1. Execute a configuration utility and enable your choice of features
2. Run make dep to build a dependency tree
3. Run make to build the package
4. Install the binary and a series of
You can build and install BusyBox on your development workstation or your target embedded system. BusyBox works equally well in both environments. However, you must take care when installing on your development workstation that you keep it isolated in a working directory, to avoid overwriting your system's startup files or primary utilities.
11.2. BusyBox Configuration
To initiate the BusyBox configuration, the command is the same as that used with the Linux kernel for the ncurses library-based configuration utility:
$ make menuconfig
Figure 11-1 shows the top-level BusyBox configuration.
Figure 11-1. Top-Level BusyBox Configuration menu
Space does not permit coverage of each configuration option. However, some of the options deserve mention. Some of the more important BusyBox configuration options are found under Build Options. Here you will find configuration options necessary to cross-compile the BusyBox application. Listing 11-1 details the options found under BuildOptions in a recent BusyBox snapshot. Select Build Options from the top-level BusyBox configuration utility to navigate to this screen.
Listing 11-1. BusyBox Build Options
[ ] Build BusyBox as a static binary (no shared libs)
[ ] Build with Large File Support (for accessing files > 2 GB)
[ ] Do you want to build BusyBox with a Cross Compiler?
() Any extra CFLAGS options for the compiler?
The first option is useful for building very minimal embedded systems. It allows BusyBox to be compiled and linked statically so that no dynamically loaded libraries (libc-2.3.3.so, for example) are required at runtime on the target system. Without this option, BusyBox requires some libraries so it can run. We can easily determine what libraries BusyBox (or any other binary) requires on our target system by using the ldd command. Listing 11-2 contains the output as displayed on my desktop Linux workstation.
Listing 11-2. BusyBox Library Dependencies
$ ldd busybox
linux-gate.so.1 => (0xffffe000)
libc.so.6=> /lib/tls/libc.so.6 (0x42c70000)
/lib/ld-linux.so.2=> /lib/ld-linux.so.2 (0x42c57000)
Notice that the BusyBox utility, as compiled using the default configuration, requires the three shared libraries in Listing 11-2. Had we elected to build BusyBox as a static binary, ldd would simply issue a message telling us that the BusyBox binary is not a dynamic executable. In other words, it requires no shared libraries to resolve any unresolved dependencies in the executable. Static linking yields a smaller footprint on a root file system because no shared libraries are required. However, building an embedded application without shared libraries means that you have none of the familiar C library functions available to your applications.
We cover the other options from Listing 11-1 in the next section.
11.2.1. Cross-Compiling BusyBox
As mentioned at the beginning of the chapter, the authors of BusyBox intended the package to be used in a cross-development environment, so building BusyBox in such an environment is quite easy. In most cases, the only requirement is to specify the prefix to the cross-compiler on your development workstation. This is specified in Build Options in the BusyBox configuration utility by selecting the option to build BusyBox with a cross-compiler. You then are presented with an option to enter the cross-compiler prefix. The prefix you enter depends on your cross- development environment. Some examples include xscale_be- or ppc-linux-. We cover this in more detail in the next chapter when we examine the embedded development environment.
The final option in Listing 11-1 is for any extra flags you might want to include on the compiler command line. These might include options for generating debug information (-g), options for setting the optimization level (-O2, for example), and other compiler options that might be unique to your particular installation and target system.
