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.
9.7.1. Root File System on NFS
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
Notice that the NFS file system support has been selected, along with support for 'Root file system on NFS.' After these kernel-configuration parameters have been selected, all that remains is to somehow feed information to the kernel so that it knows where to look for the NFS server. Several methods can be used for this, and some depend on the chosen target architecture and choice of bootloader. At a minimum, the kernel can be passed the proper parameters on the kernel command line to configure its IP port and server information on power-up. A typical kernel command line might look like this:
console=ttyS0,115200 ip=bootp root=/dev/nfs
This tells the kernel to expect a root file system via NFS and to obtain the relevant parameters (server name, server IP address, and root directory to mount) from a BOOTP server. This is a common and tremendously useful configuration during the development phase of a project. If you are statically configuring your target's IP address, your kernel command line might look like this:
console=ttyS0,115200
