Section 9.8. Pseudo File Systems

9.8. Pseudo File Systems

A number of file systems fall under the category of Pseudo File Systems in the kernel-configuration menu. Together they provide a range of facilities useful in a wide range of applications. For additional information, especially on the proc file system, spend an afternoon poking around this useful system facility. Where appropriate, references to additional reading material can be found in Section 9.11.1, at the end of this chapter.

9.8.1. Proc File System

The /proc file system took its name from its original purpose, an interface that allows the kernel to communicate information about each running process on a Linux system. Over the course of time, it has grown and matured to provide much more than process information. We introduce the highlights here; a complete tour of the /proc file system is left as an exercise for the reader.

The /proc file system has become a virtual necessity for all but the simplest of Linux systems, even embedded ones. Many user-level functions rely on the contents of the /proc file system to do their job. For example, the mount command, issued without any parameters, lists all the currently active mount points on a running system, from the information delivered by /proc/mounts. If the /proc file system is not available, the mount command silently returns. Listing 9-14 illustrates this on the ADI Engineering Coyote board.

Listing 9-14. Mount Dependency on /proc

# mount rootfs on / type rootfs (rw) /dev/root on / type nfs (rw,v2,rsize=4096,wsize=4096,hard,udp,nolock,addr=192.168.1.19) tmpfs on /dev/shm type tmpfs (rw) /proc on /proc type proc (rw,nodiratime) < Now unmount proc and try again ...> # umount /proc # mount #

Notice in Listing 9-14 that /proc itself is listed as a mounted file system, as type proc mounted on /proc. This is not doublespeak; your system must have a mount point called /proc at the top-level directory tree as a destination for the /proc file system to be mounted on.^[6] To mount the /proc file system, use the mount command as with any other file system:

^[6] It is certainly possible to mount /proc anywhere you like on your file system, but all the utilities (including mount) that require proc expect to find it mounted on /proc.

$ mount -t proc /proc /proc

The general form of the mount command, from the man page, is mount [-t fstype] something somewhere. In the previous invocation, we could have substituted none for /proc, as follows:

$ mount -t proc none /proc

This looks somewhat less like doublespeak. The something parameter is not strictly necessary because /proc is a pseudo file system and not a real physical device. However, specifying /proc as in the earlier example helps remind us that we are mounting the /proc file system on the /proc directory (or, more appropriately, on the /proc mount point).

Of course, by this time, it might be obvious that to get /proc file system functionality, it must be enabled in the kernel configuration. This kernel-configuration option can be found in the File Systems submenu under the category Pseudo File Systems.

Each user process running in the kernel is represented by an entry in the /proc file system. For example, the init process introduced in Chapter 6 is always assigned the process id (PID) of 1. Processes in the /proc file system are represented by a directory that is given the PID number as its name. For example, the init process with a PID of 1 would be represented by a /proc/1 directory. Listing 9-15 shows the contents of this directory on our embedded Coyote board.

Listing 9-15. init Process /proc EnTRies

# ls -l /proc/1 total 0 -r--------    1 root  root   0 Jan  1 00:25 auxv -r--r--r--    1 root  root   0 Jan  1 00:21 cmdline lrwxrwxrwx    1 root  root   0 Jan  1 00:25 cwd -> / -r--------    1 root  root   0 Jan  1 00:25 environ lrwxrwxrwx    1 root  root   0 Jan  1 00:25 exe -> /sbin/init dr-x------    2 root  root   0 Jan  1 00:25 fd -r--r--r--    1 root  root   0 Jan  1 00:25 maps -rw-------    1 root  root   0 Jan  1 00:25 mem -r--r--r--    1 root  root   0 Jan  1 00:25 mounts -rw-r--r--    1 root  root   0 Jan  1 00:25 oom_adj -r--r--r--    1 root  root   0 Jan  1 00:25 oom_score lrwxrwxrwx    1 root  root   0 Jan  1 00:25 root -> / -r--r--r--    1 root  root   0 Jan  1 00:21 stat -r--r--r--    1 root  root   0 Jan  1 00:25 statm -r--r--r--    1 root  root   0 Jan  1 00:21 status dr-xr-xr-x    3 root  root   0 Jan  1 00:25 task -r--r--r--    1 root  root   0 Jan  1 00:25 wchan

These entries, which are present in the /proc file system for each running process, contain much useful information, especially for analyzing and debugging a process. For example, the cmdline entry contains the complete command line used to invoke the process, including any arguments. The cwd and root directories contain the processes' view of the current working directory and the current root directory.

One of the more useful entries for system debugging is the maps entry. This contains a list of each virtual memory segment assigned to the program, along with attributes about each. Listing 9-16 is the output from /proc/1/maps in our example of the init process.

Listing 9-16. init Process Memory Segments from /proc

# cat /proc/1/maps 00008000-0000f000 r-xp 00000000 00:0a 9537567    /sbin/init 00016000-00017000 rw-p 00006000 00:0a 9537567    /sbin/init 00017000-0001b000 rwxp 00017000 00:00 0 40000000-40017000 r-xp 00000000 00:0a 9537183    /lib/ld-2.3.2.so 40017000-40018000 rw-p 40017000 00:00 0 4001f000-40020000 rw-p 00017000 00:0a 9537183    /lib/ld-2.3.2.so 40020000-40141000 r-xp 00000000 00:0a 9537518    /lib/libc-2.3.2.so 40141000-40148000 ---p 00121000 00:0a 9537518    /lib/libc-2.3.2.so 40148000-4014d000 rw-p 00120000 00:0a 9537518    /lib/libc-2.3.2.so 4014d000-4014f000 rw-p 4014d000 00:00 0 befeb000-bf000000 rwxp befeb000 00:00 0 #

The usefulness of this information is readily apparent. You can see the program segments of the init process itself in the first two entries. You can also see the memory segments used by the shared library objects being used by the init process. The format is as follows:

vmstart-vmend attr  pgoffset  devname inode filename

Here, vmstart and vmend are the starting and ending virtual memory addresses, respectively; attr indicates memory region attributes, such as read, write, and execute, and tells whether this region is shareable; pgoffset is the page offset of the region (a kernel virtual memory parameter); and devname, displayed as xx:xx, is a kernel representation of the device ID associated with this memory region. The memory regions that are not associated with a file are also not associated with a device, thus the 00:00. The final two entries are the inode and file associated with the given memory region. Of course, if there is no file, there is no inode associated with it, and it displays with a zero. These are usually data segments.

Other useful entries are listed for each process. The status entry contains useful status information about the running process, including items such as the parent PID, user and group IDs, virtual memory usage stats, signals, and capabilities. More details can be obtained from the references at the end of the chapter.

Some frequently used /proc enTRies are cpuinfo, meminfo, and version. The cpuinfo enTRy lists attributes that the kernel discovers about the processor(s) running on the system. The meminfo enTRy provides statistics on the total system memory. The version entry mirrors the Linux kernel version string, together with information on what compiler and machine were used to build the kernel.

Many more useful /proc entries are provided by the kernel; we have only scratched the surface of this useful subsystem. Many utilities have been designed for extracting and reporting information contained with the /proc file system. Two popular examples are top and ps, which every embedded Linux developer should be intimately familiar with. These are introduced in Chapter 13. Other utilities useful for interfacing with the /proc file system include free, pkill, pmap, and uptime. See the procps package for more details.

9.8.2. sysfs

Like the /proc file system, sysfs is not representative of an actual physical device. Instead, sysfs models specific kernel objects such as physical devices and provides a way to associate devices with device drivers. Some agents in a typical Linux distribution depend on the information on sysfs.

We can get some idea of what kinds of objects are exported by looking directly at the directory structure exported by sysfs. Listing 9-17 shows the top-level /sys directory on our Coyote board.

Listing 9-17. Top-Level /sys Directory Contents

# dir /sys total 0 drwxr-xr-x   21 root    root    0 Jan  1 00:00 block drwxr-xr-x    6 root    root    0 Jan  1 00:00 bus drwxr-xr-x   10 root    root    0 Jan  1 00:00 class drwxr-xr-x    5 root    root    0 Jan  1 00:00 devices drwxr-xr-x    2 root    root    0 Jan  1 00:00 firmware drwxr-xr-x    2 root    root    0 Jan  1 00:00 kernel drwxr-xr-x    5 root    root    0 Jan  1 00:00 module drwxr-xr-x    2 root    root    0 Jan  1 00:00 power #

As you can see, sysfs provides a subdirectory for each major class of system device, including the system buses. For example, under the block subdirectory, each block device is represented by a subdirectory entry. The same holds true for the other directories at the top level.

Most of the information stored by sysfs is in a format more suitable for machines than humans to read. For example, to discover the devices on the PCI bus, one could look directly at the /sys/bus/pci subdirectory. On our Coyote board, which has a single PCI device attached (an Ethernet card), the directory looks like this:

# ls /sys/bus/pci/devices/ 0000:00:0f.0 -> ../../../devices/pci0000:00/0000:00:0f.0

This entry is actually a symbolic link pointing to another node in the sysfs directory tree. We have formatted the output of ls here to illustrate this, while still fitting in a single line. The name of the symbolic link is the kernel's representation of the PCI bus, and it points to a devices subdirectory called pci0000:00 (the PCI bus representation), which contains a number of subdirectories and files representing attributes of this specific PCI device. As you can see, the data is rather difficult to discover and parse.

A useful utility exists to browse the sysfs file system directory structure. Called systool, it comes from the sysfsutils package found on sourceforge.net. Here is how systool would display the PCI bus from the previous discussion:

$ systool -b pci     Bus = "pci"     0000:00:0f.0 8086:1229

Again we see the kernel's representation of the bus and device (0f), but this time the tool displays the vendor ID (8086 = Intel) and device ID (1229 = eepro100 Ethernet card) obtained from the /sys/devices/pci0000:00 branch of /sys where these attributes are kept. Executed with no parameters, systool displays the top-level system hierarchy. Listing 9-18 is an example from our Coyote board.

Listing 9-18. Output from systool

$ systool Supported sysfs buses:         i2c         ide         pci         platform Supported sysfs classes:         block         i2c-adapter         i2c-dev         input         mem         misc         net         pci_bus         tty Supported sysfs devices:         pci0000:00         platform         system

You can see from this listing the variety of system information available from sysfs. Many utilities use this information to determine the characteristics of system devices or to enforce system policies, such as power management and hot-plug capability.