Now, it is time to start populating the root filesystem with the essential programs and the supporting libraries, configuration, and data files that it needs to operate, beginning with an overview of the types of program you will need.
You have seen in the previous chapter that init is the first program to be run and so has PID 1. It runs as the root user and so has maximum access to system resources. Usually, it runs shell scripts which start daemons: a daemon is a program that runs in the background with no connection to a terminal, in other places it would be called a server program.
We need a shell to run scripts and to give us a command-line prompt so that we can interact with the system. An interactive shell is probably not necessary in a production device, but it is useful for development, debugging, and maintenance. There are various shells in common use in embedded systems:
bash: is the big beast that we all know and love from desktop Linux. It is a superset of the Unix Bourne shell, with many extensions or bashisms.ash: also based on the Bourne shell, and has a long history with the BSD variants of Unix. Busybox has a version of ash which has been extended to make it more compatible withbash. It is much smaller thanbashand hence is a very popular choice for embedded systems.hush: is a very small shell that we briefly looked at in the chapter on bootloaders. It is useful on devices with very little memory. There is a version in BusyBox.
The shell is just a way of launching other programs and a shell script is little more than a list of programs to run, with some flow control and a means of passing information between programs. To make a shell useful, you need the utility programs that the Unix command-line is based on. Even for a basic root filesystem, there are approximately 50 utilities, which presents two problems. Firstly, tracking down the source code for each and cross compiling it would be quite a big job. Secondly, the resulting collection of programs would take up several tens of megabytes, which was a real problem in the early days of embedded Linux when a few megabytes was all you had. To solve this problem, BusyBox was born.
The genesis of BusyBox had nothing to do with embedded Linux. The project was instigated in 1996 by Bruce Perens for the Debian installer so that he could boot Linux from a 1.44 MB floppy disk. Coincidentally, that was about the size of the storage on contemporary devices and so the embedded Linux community quickly took it up. BusyBox has been at the heart of embedded Linux ever since.
BusyBox was written from scratch to perform the essential functions of those essential Linux utilities. The developers took advantage of the 80:20 rule: the most useful 80% of a program is implemented in 20% of the code. Hence, BusyBox tools implement a subset of the functions of the desktop equivalents, but they do enough to be useful in the majority of cases.
Another trick BusyBox employs is to combine all the tools together into a single binary, making it easy to share code between them. It works like this: BusyBox is a collection of applets, each of which exports its main function in the form [applet]_main. For example, the cat command is implemented in coreutils/cat.c and exports cat_main. The main function of BusyBox itself dispatches the call to the correct applet based on the command-line arguments.
So, to read a file, you can launch busybox with the name of the applet you want to run, followed by any arguments the applet expects, as shown here:
$ busybox cat my_file.txt
You can also run busybox with no arguments to get a list of all the applets that have been compiled.
Using BusyBox in this way is rather clumsy. A better way to get BusyBox to run the cat applet is to create a symbolic link from /bin/cat to /bin/busybox:
$ ls -l bin/cat bin/busybox -rwxr-xr-x 1 chris chris 892868 Feb 2 11:01 bin/busybox lrwxrwxrwx 1 chris chris 7 Feb 2 11:01 bin/cat -> busybox
When you type cat at the command line, busybox is the program that actually runs. BusyBox only has to check the command tail passed in argv[0], which will be /bin/cat, extract the application name, cat, and do a table look-up to match cat with cat_main. All this is in libbb/appletlib.c in this section of code (slightly simplified):
applet_name = argv[0]; applet_name = bb_basename(applet_name); run_applet_and_exit(applet_name, argv);
BusyBox has over three hundred applets including an init program, several shells of varying levels of complexity, and utilities for most admin tasks. There is even a simple version of the vi editor so you can change text files on your device.
To summarize, a typical installation of BusyBox consists of a single program with a symbolic link for each applet, but which behaves exactly as if it were a collection of individual applications.
BusyBox uses the same Kconfig and Kbuild system of the kernel, so cross compiling is straightforward. You can get the source by cloning the git archive and checking out the version you want (1_24_1 was the latest at the time of writing), like this:
$ git clone git://busybox.net/busybox.git $ cd busybox $ git checkout 1_24_1
You can also download the corresponding tarball file from http://busybox.net/downloads. Then, configure BusyBox, starting in this case with the default configuration, which enables pretty much all of the features of BusyBox:
$ make distclean $ make defconfig
At this point, you probably want to run make menuconfig to fine tune the configuration. You almost certainly want to set the install path in Busybox Settings | Installation Options (CONFIG_PREFIX) to point to the staging directory. Then, you can cross compile in the usual way:
$ make -j 4 ARCH=arm CROSS_COMPILE=arm-cortex_a8-linux-gnueabihf-
The result is the executable, busybox. For a defconfig build for ARM v7a, it comes out at about 900 KiB. If that is too big for you, you can slim it down by configuring out the utilities you don't need.
To install BusyBox, use the following command:
$ make install
This will copy the binary to the directory configured in CONFIG_PREFIX and create all the symbolic links to it.
BusyBox is not the only game in town. For example, Android has an equivalent named Toolbox, but it is more tuned to the needs of Android and not useful in a general purpose embedded environment. A more useful option is ToyBox, a project started and maintained by Rob Landley, who was previously a maintainer of BusyBox. ToyBox has the same aim as BusyBox, but with more emphasis on complying with standards, especially POSIX-2008 and LSB 4.1, and less on compatibility with GNU extensions to those standards. ToyBox is smaller than BusyBox, partly because it implements fewer applets.
However, the main difference is the license, BSD rather than GPL v2, which makes it license-compatible with operating systems with a BSD-licensed user space, such as Android itself.