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

drwxr-xr-x 1 root root 172 Dec 31 1969 lib

drwxr-xr-x 1 root root 0 Dec 31 1969 proc

drws------ 1 root root 0 Dec 31 1969 root

drwxr-xr-x 1 root root 272 Dec 31 1969 sbin

drwxrwxrwt 1 root root 0 Dec 31 1969 tmp

drwxr-xr-x 1 root root 124 Dec 31 1969 usr

drwxr-xr-x 1 root root 212 Dec 31 1969 var

#

You might have noticed the warning message regarding group ID (GID) when the mkcramfs command was executed. The cramfs file system uses very terse metadata to reduce file system size and increase the speed of execution. One of the "features" of the cramfs file system is that it truncates the group ID field to 8 bits. Linux uses 16-bit group ID field. The result is that files created with group IDs greater than 255 are truncated with the warning issued in Listing 9-10.

Although somewhat limited in terms of maximum file sizes, maximum number of files, and so on, the cramfs file system is ideal for boot ROMS, in which read-only operation and fast compression are ideally suited.

Those of you who have developed in the UNIX environment will undoubtedly be familiar with the Network File System, or simply NFS. Properly configured, NFS enables you to export a directory on an NFS server and mount that directory on a remote client machine as if it were a local file system. This is useful in general for large networks of UNIX/Linux machines, and it can be a panacea to the embedded developer. Using NFS on your target board, an embedded developer can have access to a huge number of files, libraries, tools, and utilities during development and debugging, even if the target embedded system is resource constrained.

As with the other file systems, your kernel must be configured with NFS support, for both the server-side functionality and the client side. NFS server and client functionality is independently configured in the kernel configuration.

Detailed instructions for configuring and tuning NFS are beyond the scope of this book, but a short introduction helps to illustrate how useful NFS can be in the embedded environment. See Section 9.11.1 at the end of this chapter for a pointer to detailed information about NFS, including the complete NFS-Howto.

On your development workstation with NFS enabled, a file contains the names of each directory that you want to export via the Network File System. On Red Hat and other distributions, this file is located in the /etc directory and is named exports. Listing 9-12 illustrates a sample /etc/exports such as might be found on a development workstation used for embedded development.

Listing 9-12. Contents of /etc/exports

$ cat /etc/exports

# /etc/exports

/home/chris/sandbox/coyote-target *(rw,sync,no_root_squash)

/home/chris/workspace *(rw,sync,no_root_squash)

$

This file contains the names of two directories on a Linux development workstation. The first directory contains a target file system for an ADI Engineering Coyote reference board. The second directory is a general workspace that contains projects targeted for an embedded system. This is arbitrary; you can set things up any way you choose.

On an embedded system with NFS enabled, the following command mounts the .../workspace directory exported by the NFS server on a mount point of our choosing:

$ mount -t nfs pluto:/home/chris/workspace /workspace

Notice some important points about this command. We are instructing the mount command to mount a remote directory (on a machine named pluto) onto a local mount point called /workspace. For this syntax to work, two requirements must be met on the embedded target. First, for the target to recognize the symbolic machine name pluto, it must be capable of resolving the symbolic name. The easiest way to do this is to place an entry in the /etc/hosts file on the target. This allows the networking subsystem to resolve the symbolic name to its corresponding IP address. The entry in the target's /etc/hosts file would look like this:

192.168.10.9 pluto

The second requirement is that the embedded target must have a directory in its root directory called /workspace. This is called a mount point. The previous mount command causes the contents of the NFS server's /home/chris/workspace directory to be available on the embedded system's /workspace path.

This is quite useful, especially in a cross-development environment. Let's say that you are working on a large project for your embedded device. Each time you make changes to the project, you need to move that application to your target so you can test and debug it. Using NFS in the manner just described, assuming that you are working in the NFS exported directory on your host, the changes are immediately available on your target embedded system without the need to upload the newly compiled project files. This can speed development considerably.

Mounting your project workspace on your target embedded system is very useful for development and debugging because it facilitates rapid access to changes and source code for source-level debugging. This is especially useful when the target system is severely resource constrained. NFS really shines as a development tool when you mount your embedded system's root file system entirely from an NFS server. From Listing 9-12, notice the coyote-target enTRy. This directory on your development workstation could contain hundreds or thousands of files compatible with your target architecture.

The leading embedded Linux distributions targeted at embedded systems ship tens of thousands of files compiled and tested for the chosen target architecture. To illustrate this, Listing 9-13 contains a directory listing of the coyote-target directory referenced in Listing 9-12.

Listing 9-13. Target File System Example Summary

$ du -h --max-depth=1

724M ./usr

4.0K ./opt

39M ./lib

12K ./dev

27M ./var

4.0K ./tmp

3.6M ./boot

4.0K ./workspace

1.8M ./etc

4.0K ./home

4.0K ./mnt

8.0K ./root

29M ./bin

32M ./sbin

4.0K ./proc

64K ./share

855M .

$

$ find -type f | wc -l

29430

This target file system contains just shy of a gigabyte worth of binary files targeted at the ARM architecture. As you can see from the listing, this is more than 29,000 binary, configuration and documentation files. This would hardly fit on the average Flash device found on an embedded system!

This is the power of an NFS root mount. For development purposes, it can only increase productivity if your embedded system is loaded with all the tools and utilities you are familiar with on a Linux workstation. Indeed, likely dozens of command line tools and development utilities that you have never seen can help you shave time off your development schedule. You will learn more about some of these useful tools in Chapter 13, "Development Tools."

To enable your embedded system to mount its root file system via NFS at boot time is relatively straightforward. First, you must configure your target's kernel for NFS support. There is also a configuration option to enable root mounting of an NFS remote directory. This is illustrated in Figure 9-3.

Figure 9-3. NFS kernel configuration