Christopher Hallinan - Embedded Linux Primer - A Practical, Real-World Approach

[root@coyote]# ./busybox ls

Another important message from the BusyBox usage message in Listing 11-3 is the short description of the program. It describes BusyBox as a multicall binary, combining many common utilities into a single executable. This is the purpose of the symlinks mentioned earlier. BusyBox was intended to be invoked by a symlink named for the function it will perform. This removes the burden of having to type a two-word command to invoke a given function, and it presents the user with a set of familiar commands for the similarly named utilities. Listings 11-4 and 11-5 should make this clear.

Listing 11-4. BusyBox Symlink StructureTop Level

[root@coyote]$ ls -l /

total 12

drwxrwxr-x 2 root root 4096 Dec 3 13:38 bin

lrwxrwxrwx 1 root root 11 Dec 3 13:38 linuxrc -> bin/busybox

drwxrwxr-x 2 root root 4096 Dec 3 13:38 sbin

drwxrwxr-x 4 root root 4096 Dec 3 13:38 usr

Listing 11-4 shows the target directory structure as built by the BusyBox package via the make install command. The executable busybox file is found in the /bin directory, and symlinks have been populated throughout the rest of the structure pointing back to /bin/busybox. Listing 11-5 expands on the directory structure of Listing 11-4.

Listing 11-5. BusyBox Symlink StructureTree Detail

[root@coyote]$ tree

.

|-- bin

| |-- ash -> busybox

| |-- busybox

| |-- cat -> busybox

| |-- cp -> busybox

| |-- ...

| '-- zcat -> busybox

|-- linuxrc -> bin/busybox

|-- sbin

| |-- halt -> ../bin/busybox

| |-- ifconfig -> ../bin/busybox

| |-- init -> ../bin/busybox

| |-- klogd -> ../bin/busybox

| |-- ...

| '-- syslogd -> ../bin/busybox

'-- usr

|-- bin

| |-- [ -> ../../bin/busybox

| |-- basename -> ../../bin/busybox

|-- ...

| |-- xargs -> ../../bin/busybox

| '-- yes -> ../../bin/busybox

'-- sbin

'-- chroot -> ../../bin/busybox

The output of Listing 11-5 has been significantly truncated for readability and to avoid a three-page listing. Each line containing an ellipsis (...) indicates that this listing has been pruned to show only the first few and last few entries of that given directory. In actuality, more than 100 symlinks can be populated in these directories, depending on what functionality you have enabled using the BusyBox configuration utility.

Notice the busybox executable itself, the second entry from the /bin directory. Also in the /bin directory are symlinks pointing back to busybox for ash, cat, cp ... all the way to zcat. Again, the entries between cp and zcat have been omitted from this listing for readability. With this symlink structure, the user simply enters the actual name of the utility to invoke its functionality. For example, to configure a network interface using the busybox ifconfig utility, the user might enter a command similar to this:

$ ifconfig eth1 192.168.1.14

This would invoke the busybox executable through the ifconfig symlink. BusyBox examines how it was calledthat is, it reads argv[0] to determine what functionality is executed.

Notice the symlink in Listing 11-5 called init. In Chapter 6 "System Initialization," you learned about the init program and its role in system initialization. Recall that the kernel attempts to execute a program called /sbin/init as the last step in kernel initialization. There is no reason why BusyBox can't emulate the init functionality, and that's exactly how the system illustrated by Listing 11-5 is configured. BusyBox handles the init functionality.

BusyBox handles system initialization differently from standard System V init. A Linux system using the System V (SysV) initialization as described in Chapter 6 requires an inittab file accessible in the /etc directory. BusyBox also reads an inittab file, but the syntax of the inittab file is different. In general, you should not need to use an inittab if you are using BusyBox. I agree with the BusyBox man page: If you need run levels, use System V initialization. [78] We covered the details of System V initialization in Chapter 6.

Let's see what this looks like on an embedded system. We have created a small root file system based on BusyBox. We configured BusyBox for static linking, eliminating the need for any shared libraries. Listing 11-6 contains a tree listing of this root file system. We built this small file system using the steps outlined in Chapter 9, "File Systems," Section 9.10, "Building a Simple File System." We do not detail the procedure again here. The files in our simple file system are those shown in Listing 11-6.

Listing 11-6. Minimal BusyBox Root File System

$ tree

.

|-- bin

| |-- busybox

| |-- cat -> busybox

| |-- dmesg -> busybox

| |-- echo -> busybox

| |-- hostname -> busybox

| |-- ls -> busybox

| |-- ps -> busybox

| |-- pwd -> busybox

| '-- sh -> busybox

|-- dev

| '-- console

|-- etc

'-- proc

4 directories, 10 files

This BusyBox-based root file system occupies little more than the size needed for busybox itself. In this configuration, using static linking and supporting nearly 100 utilities, the BusyBox executable came in at less than 1MB:

# ls -l /bin/busybox

-rwxr-xr-x 1 root root 824724 Dec 3 2005 /bin/busybox

Now let's see how this system behaves. Listing 11-7 captures the console output on power-up on this BusyBox-based embedded system.

Listing 11-7. BusyBox Default Startup

...

Looking up port of RPC 100003/2 on 192.168.1.9

Looking up port of RPC 100005/1 on 192.168.1.9

VFS: Mounted root (nfs filesystem).

Freeing init memory: 96K

Bummer, could not run '/etc/init.d/rcS': No such file or directory

Please press Enter to activate this console.

BusyBox v1.01 (2005.12.03-19:09+0000) Built-in shell (ash)

Enter 'help' for a list of built-in commands.

-sh: can't access tty; job control turned off

/ #

The example of Listing 11-7 was run on an embedded board configured for NFS root mount. We export a directory on our workstation that contains the simple file system image detailed in Listing 11-6. As oneof the final steps in the boot process, the Linux kernel on our target board mounts a root file system via NFS. When the kernel attempts to execute /sbin/init, it fails because there is no /sbin/init on our file system. However, as we have seen, the kernel also attempts to execute /bin/sh. In our BusyBox-configured target, this succeeds, and busybox is launched via the symlink /bin/sh on our root file system.

The first thing BusyBox displays is the complaint that it can't find /etc/init.d/rcS. This is the default initialization script that BusyBox searches for. Instead of using inittab, this is the preferred method to initialize an embedded system based on BusyBox.