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

GNU Compiler Collection documentation:

http://gcc.gnu.org/onlinedocs/gcc [46] Especially the sections on function attributes, type attributes, and variable attributes.

Using LD, the GNU linker

http://www.gnu.org/software/binutils/manual/ld-2.9.1/ld.html

Kernel documentation:

.../Documentation/kernel-parameters.txt

In Chapter 2, "Your First Embedded Experience," we pointed out that the Linux kernel itself is but a small part of any embedded Linux system. After the kernel has initialized itself, it must mount a root file system and execute a set of developer-defined initialization routines. In this chapter, we examine the details of post-kernel system initialization.

We begin by looking at the root file system and its layout. Next we develop and study a minimal system configuration. Later in this chapter, we add functionality to the minimal system configuration to produce useful example embedded system configurations. We complete the coverage of system initialization by introducing the initial ramdisk , or initrd, and its operation and use. The chapter concludes with a brief look at Linux shutdown logic.

In Chapter 5, "Kernel Initialization," we examined the Linux kernel's behavior during the initialization process. We made several references to mounting a root file system . Linux, like many other advanced operating systems, requires a root file system to realize the benefits of its services. Although it is certainly possible to use Linux in an environment without a file system, it makes little sense because most of the features and value of Linux would be lost. It would be similar to putting your entire system application into an overbloated device driver or kernel thread.

The root file system refers to the file system mounted at the base of the file system hierarchy, designated simply as /. As you will discover in Chapter 9, "File Systems," even a small embedded Linux system typically mounts several file systems on different locations in the file system hierarchy. The proc file system, introduced in Chapter 9, is an example. It is a special-purpose file system mounted at /proc under the root file system. The root file system is simply the first file system mounted at the base of the file system hierarchy.

As you will shortly see, the root file system has special requirements for a Linux system. Linux expects the root file system to contain programs and utilities to boot a system, initialize services such as networking and a system console, load device drivers, and mount additional file systems.

Several kernel developers authored a standard governing the organization and layout of a UNIX file system. The File System Hierarchy Standard (FHS) establishes a minimum baseline of compatibility between Linux distributions and application programs. You'll find a reference to this standard in Section 6.7.1 "Suggestions for Additional Reading" at the end of this chapter. You are encouraged to review the FHS standard for a better background on the layout and rationale of UNIX file system organization.

Many Linux distributions have directory layouts closely matching that described in the FHS standard. The standard exists to provide one element of a common base between different UNIX and Linux distributions. The FHS standard allows your application software (and developers) to predict where certain system elements, including files and directories, can be found on the file system.

Where space is a concern, many embedded systems developers create a very small root file system on a bootable device (such as Flash memory) and later mount a larger file system from another device, perhaps a hard disk or network NFS server. In fact, it is not uncommon to mount a larger root file system right on top of the original small one. You'll see an example of that when we examine the initial ramdisk (initrd) later in this chapter.

A simple Linux root file system might contain the following top-level directory entries:

.

|

|--bin

|--dev

|--etc

|--lib

|--sbin

|--usr

|--var

|--tmp

Table 6-1 details the most common contents of each of these root directory entries.

Table 6-1. Top-Level Directories

The very top of the Linux file system hierarchy is referenced by the forward slash character (/) by itself. For example, to list the contents of the root directory, one would type this:

$ ls /

This produces a listing similar to the following:

root@coyote:/# ls /

bin dev etc home lib mnt opt proc root sbin tmp usr var

root@coyote:/#

This directory listing contains directory entries for additional functionality, including /mnt and /proc. Notice that we reference these directory entries preceded by the forward slash, indicating that the path to these top-level directories starts from the root directory.

To illustrate the requirements of the root file system, we have created a minimal root file system. This example was produced on the ADI Engineering Coyote Reference board using an XScale processor. Listing 6-1 is the output from the TRee command on this minimal root file system.

Listing 6-1. Contents of Minimal Root File System

.

|-- bin

|

| |-- busybox

|

| '-- sh -> busybox

|-- dev

|

| '-- console

|-- etc

|

| '-- init.d

|

| '-- rcS

'-- lib

|-- ld-2.3.2.so

|-- ld-linux.so.2 -> ld-2.3.2.so

|-- libc-2.3.2.so

'-- libc.so.6 -> libc-2.3.2.so

5 directories, 8 files

This root configuration makes use of busybox, a popular and aptly named toolkit for embedded systems. In short, busybox is a stand-alone binary that provides support for many common Linux command line utilities. busybox is so pertinent for embedded systems that we devote Chapter 11, "BusyBox," to this flexible utility.

Notice in our example minimum file system in Listing 6-1 that there are only eight files in five directories. This tiny root file system boots and provides the user with a fully functional command prompt on the serial console. Any commands that have been enabled in busybox [48] BusyBox commands are covered in Chapter 11. are available to the user.

Starting from /bin, we have the busybox executable and a soft link called sh pointing back to busybox. You will see shortly why this is necessary. The file in /dev is a device node [49] Device nodes are explained in detail in Chapter 8. required to open a console device for input and output. Although it is not strictly necessary, the rcS file in the /etc/init.d directory is the default initialization script processed by busybox on startup. Including rcS silences the warning message issued by busybox if rcS is missing.