From: http://www.mike.org.cn/articles/linux-understand-devfs-sysfs-udev/
In Linux, there is a dedicated File System for device management. devfs and sysfs are two of them.
I. devfs
Devfs appeared in the 2.4 kernel, which is used to solve the problem of device management confusion in Linux, you can check the device files in/dev to find that many of them are empty (that is, there is no corresponding hardware), but they must exist, this causes a lot of trouble for Linux device management. To solve this problem, Linux kernel developers developed devfs and used a daemon devfsd to implement compatibility with previous hardware drivers.
Both devfs and sysfs are similar to proc and are virtual file systems. devfs creates corresponding device files under/dev for the drivers registered with devfs. However, for compatibility purposes, the devfsd daemon will create a device file indexed by the primary device in a specified directory. If this is not done, many previous applications will not be able to run.
Before kernel 2.6, devfs was used. devfs was mounted to the/dev directory and provides a file-like method to manage all devices in the/dev directory, we know that each file in the/dev directory corresponds to a device. Whether or not the current device exists or not, and these special files are located on the root file system, we have created these device files when creating a file system. Therefore, by operating these special files, we can interact with the kernel.
However, the devfs file system has some disadvantages, such as uncertain device ing. Sometimes the device files mapped by a device may be different. For example, My USB flash drive may correspond to SDA and may correspond to SDB; there are not enough primary/secondary device numbers. When there are too many devices, this will obviously become a problem; too many files in the/dev directory cannot represent the actual devices on the current system; naming is not flexible enough and cannot be specified at will.
Ii. sysfs
Sysfs is a virtual file system provided by Linux 2.6. This file system can not only output device (devices) and driver (drivers) information from the kernel space to the user space, but also be used to set the device and driver.
The purpose of sysfs is to present some of the device components originally in procfs in the form of a [device hierarchy} (Device Tree. This file system was written by Patrick mochel. Later Maneesh Soni wrote the "sysfs backing store path" to reduce the memory demand in large systems.
Sysfs was initially based on ramfs and is also an archive system that only exists in memory. Ramfs was added when the 2.4 core was in a stable phase. Ramfs is an elegant practice that proves how easy it is to write a simple file system under a new Virtual File System (VFS. Due to the simplicity of ramfs and the use of VFS, some memory file systems later use it as the basis for development.
Sysfs was initially named DDFs (Device Driver filesystem) and was originally developed to debug the new driver model. In addition to errors, the Device Tree information is output to the procfs file system. However, with the urgent urging of Linus Torvalds, DDFs was transformed into a file system based on ramfs. When the new driver model is integrated into the 2.5.1 core, DDFs is renamed as driverfs to describe its purpose more accurately.
In the following year of core development in 2.5, the new 'driver model' and 'driverfs' proved to be useful for other subsystems in the core. Kobjects was developed as the central management mechanism for core objects, and driverfs was renamed sysfs.
Because of these problems in devfs, a new file system sysfs is introduced after the Linux kernel, Which is mounted to the/sys directory, like devfs, it is also a virtual file system used to manage system devices. It organizes devices and bus actually connected to the system into a hierarchical file, user space programs can also use this information to interact with the kernel.
This file system is an intuitive response to the actual device tree in the current system. It establishes this information through the kobject subsystem. When a kobject is created, the corresponding files and directories are created in the corresponding directory under/sys. Since each device has a unique directory in sysfs, it can be read and written by the user space. The user space tool udev uses the information provided by sysfs to implement all devfs functions, but the difference is that udev runs in the user space, while devfs runs in the kernel space, and udev does not have the inherent defects of devfs. Obviously, sysfs will be the future development direction.
Iii. udev
Udev is a tool that dynamically updates device files, including creating and deleting device files, based on the status of hardware devices in the system. The device files are usually stored in the/dev directory. After udev is used, only the real devices in the system are included in the/dev directory. It is independent of the hardware platform and is located in the user space. It requires support from the kernel sysfs and tmpfs. sysfs provides the device portal and uevent channel for udev, and tmpfs provides storage space for udev device files.