< Back to index
Sysfs is a virtual file system provided by the 2.6 Linux kernel. Sysfs exports information about devices and drivers from the kernel device model to userspace, and is also used for configuration.
History
During the 2.5 development cycle, the Linux driver model was introduced to fix several shortcomings of the 2.4 kernel:
* No unified method of representing driver-device relationships existed.
* There was no generic hotplug mechanism.
* procfs was cluttered with lots of non-process information.
Sysfs is designed to export the information present in the device tree which would then no longer clutter up procfs. It was written by Patrick Mochel. Maneesh Soni later wrote the sysfs backing store patch to reduce memory usage on large systems.
sysfs is an in-memory filesystem that was originally based on ramfs. ramfs was written around the time the 2.4.0 kernel was being stabilized. It was an exercise in elegance, as it showed just how easy it was to write a simple filesystem using the then-new VFS layer. Because of its simplicity and use of the VFS, it provided a good base from which to derive other in-memory based filesystems.
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 subsystems. kobjects were developed to provide a central object management mechanism and driverfs was converted to sysfs to represent its subsystem agnosticism.(Taby)
Technical Overview
For each object added in the driver model tree (drivers, devices including class devices) a directory in sysfs is created. The parent/child relationship is reflected with subdirectories under /sys/devices/ (reflecting the physical layout). The subdirectory /sys/bus/ is populated with symbolic links, reflecting how the devices belong to different busses. /sys/class/ shows devices grouped according to classes, like network, while /sys/block/ contains the block devices.
For device drivers and devices, attributes may be created. These are simple files; the rule is that they should only contain a single value and/or allow a single value to be set (unlike some files in procfs, which need to be heavily parsed). These files show up in the subdirectory of the device driver respective to the device. Using attribute groups, a subdirectory filled with attributes may also be created.
Some buses
PCI
Exports information about PCI devices.
USB
Contains both USB devices and USB hosts.
S/390 buses
As the S/390 architecture contains devices not found elsewhere, special buses have been created:
* css: Contains subchannels (currently the only driver provided is for I/O subchannels).
* ccw: Contains channel attached devices (driven by CCWs).
* ccwgroup: Artificial devices, created by the user and consisting of ccw devices. Replaces some of the 2.4 chandev functionality.
* iucv: Artificial devices like netiucv devices which use VM's IUCV interface.
Sysfs and userspace
Sysfs is used by several utilities to access information about hardware and its driver (kernel modules) such as udev or HAL. Scripts have been written to access information previously obtained via procfs, and some scripts configure device drivers and devices via their attributes.
This entry uses material from from Wikipedia, the leading user-contributed encyclopedia. It is licensed under the GNU Free Documentation License. Disclaimer.