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

# 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.

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.

Numerous file systems are supported under Linux. Space does not permit coverage of all of them. However, you should be aware of some other important file systems frequently found in embedded systems.

The ramfs file system is best considered from the context of the Linux source code module that implements it. Listing 9-19 reproduces the first several lines of that file.

Listing 9-19. Linux ramfs Source Module Comments

/*

* Resizable simple ram filesystem for Linux.

*