SysFS and proc

Certify and Increase Opportunity.
Be

Govt. Certified Linux Administrator

Back to Tutorial

In order to exchange data between user space and kernel space the Linux kernel provides a couple of RAM based file systems. These interfaces are, themselves, based on files. Usually a file represents a single value, but it may also represent a set of values. The user space can access these values by means of the standard read and write functions. For most file systems the read and write function results in a callback function in the Linux kernel which has access to the corresponding value.

Despite offering similar functionality, the different RAM based file systems are all designed for separate purposes. The benefit of using the read and write function in comparison to, for example, socket based approaches, is that the user space has a lot of tools available to send data to the kernel space (e.g. cat, echo). These programs are well known to users and they can be used in scripts.

SysFS

sysfs is a virtual file system that represents kernel objects as directories, files and symbolic links. sysfs can be used to query for information about kernel objects, and can also manipulate those objects through the use of normal file system commands. The sysfs virtual file system has a line in /etc/fstab, and is mounted under the /sys/ directory. sysfs provides functionality similar to the sysctl mechanism found in BSD operating systems, with the difference that sysfs is implemented as a virtual file system instead of being a purpose-built kernel mechanism.

The files that are created in the filesystem are (mostly) ASCII files with (usually) one value per file. These features en-sure that the information exported is accurate and easily accessible, making sysfs one of the most intuitive and useful features of the 2.6 kernel.

sysfs is a mechanism for representing kernel objects, their attributes, and their relationships with each other. It provides two components – a kernel programming interface for exporting these items via sysfs, and a user interface to view and manipulate these items that maps back to the kernel objects which they represent. The table below shows the mapping between internel (kernel) constructs and their external (userspace) sysfs mappings.

Internal	External
Kernel Objects	Directories
Object Attributes	Regular Files
Object Relationships	Symbolic Links

sysfs was originally called ddfs(Device Driver Filesystem) and was written to debug the new driver model as it was being written. That debug code had originally used procfs to export a device tree, but under strict urging from Linus Torvalds, it was converted to use a new filesystem based on ramfs. By the time the new driver model was merged into the kernel around 2.5.1, it had changed names to driverfs to be a little more descriptive. During the next year of 2.5 development, the infrastructural capabilities of the driver model and driverfs began to prove useful to other sub-systems. kobjects were developed to provide a central object management mechanism and driverfs was converted to sysfs to represent its subsystem agnosticism.

sysfs can be mounted from userspace just like any other memory-based filesystem. The command for doing so is as – mount -t sysfs sysfs /sys

sysfs can also be mounted automatically on boot using the file/etc/fstab. Most distributions that support the 2.6 kernel have entries for sysfs in/etc/fstab. An example entry is as – sysfs /sys sysfs noauto 0 0

The directory that sysfs is mounted on /sys. That is the de facto standard location for the sysfs mount point. This was adopted without objection by every major distribution. Since sysfs is simply a collection of directories, files, and symbolic links, it can be navigated and manipulated using simple shell utilities.

At the top level of the sysfs mount point are a number of directories. These directories represent the major subsystems that are registered with sysfs. These directories are created at system startup when the subsystems register themselves with the kobject core. After they are initialized, they begin to discover objects, which are registered within their respective directories.

• block – The block directory contains subdirectories for each block device that has been discovered in the system. In each block device’s directory are attributes that describe many things, including the size of the device and the dev_t number that it maps to. There is a symbolic link that points to the physical device that the block device maps to (in the physical device tree, which is explained later). And, there is a directory that exposes an interface to the I/O scheduler. This interface provides some statistics about the device request queue and some tunable features that a user or administrator can use.
• bus – The bus directory contains subdirectories for each physical bus type that has support registered in the kernel (either statically compiled or loaded via a module). Each bus type that is represented has two sub-directories: devices and drivers. The devices directory contains a flat listing of every device discovered on that type of bus in the entire system. The devices listed are actually symbolic links that point to the device’s directory in the global device tree. The drivers directory contains directories for each device driver that has been registered with the bus type. Within each of the driver’s directories are attributes that allow viewing and manipulation of driver parameters, and symbolic links that point to the physical devices (in the global device tree) that the driver is bound to.
• class – The class directory contains representations of every device class that is registered with the kernel. A device class describes a functional type of device.
• devices – The devices directory contains the global device hierarchy. This contains every physical device that has been discovered by the bus types registered with the kernel. It represents them in an ancestrally correct way—each device is shown as a subordinate device of the device that it is physically (electrically) subordinate to.
• firmware – The firmware directory contains inter-faces for viewing and manipulating firmware-specific objects and attributes. In this case, ‘firmware’ refers to the platform-specific code that is executed on system power-on, like the x86 BIOS, OpenFirmware on PPC platforms, and EFI on ia64 platforms.
• power – The power directory represents the under-used power subsystem. It currently contains only two attributes: disk which controls the method by which the system will suspend to disk; and state, which allows a process to enter a low power state. Reading this file displays which states the system supports.
• module – The module directory contains sub-directories for each module that is loaded into the kernel. The name of each directory is the name of the module—both the name of the module object file and the internal name of the module. Every module is represented here, regardless of the subsystem it registers an object with. The kernel has a single global namespace for all modules.

proc

The procfs, located in /proc, is the best known interface of this class. It was originally designed to export all kind of process information such as the current status of the process, or all open file descriptors to the user space. Despite its initial purposes, the procfs has been used for a lot of other purposes:

• provide information about the running system such as cpu information, information about interrupts, about the available memory or the version of the kernel.
• information about “ide devices”, “scsi devices” and “tty’s”.
• networking information such as the arp table, network statistics or lists of used sockets

There is a special subdirectory: /proc/sys.

It allows to configure a lot of parameters of the running system. Usually each file consists of a single value. This value may correspond to:

• a limit (e.g. maximum buffer size)
• turn on or off a given functionality (for example routing)
• or represent some other kernel variable

All directories and files below /proc/sys/ are not implemented with the procfs interface. Instead they use a mechanism called sysctl. Note, despite the wide use of the procfs, it is deprecated and should only be used to export information related to a process itself.

Configfs

The configfs is somewhat the counterpart of the sysfs. It can be seen as a filesystem based manager of kernel objects. An important difference between configfs and sysfs is that in configfs all objects are created from user space with a call to mkdir. The kernel responds with creating the attributes (files) and then they can be read and written by the user. If the user no longer needs the files, he calls rmdir and everything gets deleted. Therefore the life cycle of a configfs object is fully controlled by user space.

Each time mkdir is invoked a new “config_item” is created by the kernel implementation. This config_item represents the files (attributes), the show and store callback functions as well as the associated value. Therefore each mkdir creates a new directory along with new files which represent new values.

Configfs has the same limitations than sysfs: each file should represent only one value and it should be smaller than PAGE_SIZE bytes.

Debugfs

Debugfs is a simple to use RAM based file system especially designed for debugging purposes. Developers are encouraged to use debugfs instead of procfs in order to obtain some debugging information from their kernel code. Debugfs is quite flexible: it provides the possibility to set or get a single value with the help of just one line of code but the developer is also allowed to write its own read/write functions, and he can use the seq_file interface described in the procfs section.

Sysctl

The sysctl infrastructure is designed to configure kernel parameters at run time. The sysctl interface is heavily used by the Linux networking subsystem. It can be used to configure some core kernel parameters; represented as files in /proc/sys/*. The values can be accessed by using cat, echo or the sysctl commands. If a value is set by the echo command it only persists as long as the kernel is running, but gets lost as soon as the machine is rebooted. In order to change the values permanently they have to be written to the file /etc/sysctl.conf. Upon restarting the machine all values specified in this file are written to the corresponding files in /proc/sys/.

Each entry in the /proc/sys directory is represented by an entry in a table maintained by the Linux kernel, arranged in a hierarchy. A directory is represented by an entry pointing to a subtable. A file is represented by an entry of type struct ctl_table. This entry consists of the data represented by this file along with some access rules.

New files and directories can be added by expanding one of the subtables. In this example we add a new directory called test below the /proc/sys/net/ directory. Our directory has got two files: value1 and value2. Each of these files hold an integer variable which can have a value between 10 and 20. The user root is allowed to change the entries whereas normal user are allowed to read the entries.

Character Devices

As the name suggests, this interface was designed for character device drivers, and is commonly used for communication between user and kernel space. (For example, users with sufficient privileges my write directly to the virtual terminal 1 with echo “hi there” > /dev/tty1).

Each module can register itself as a character device and provide some read and write functions which handle the data. Files representing character devices are located within the /dev directory (where you will also find block devices, but we will not be describing them further). Usually these files correspond to a hardware device.