Sinsing analysis of Devfs, SYSFS and Udev in Linux

Linux has a dedicated file system for the management of devices, DEVFS and Sysfs are two of them. Devfs was used before the 2.6 kernel, and DEVFS is mounted in the/dev directory, providing a file-like way to manage all the devices in the/dev directory, and we know that each file in the/dev directory corresponds to a device, And these special files are located on the root file system, we have built these device files when we make the file system, so by manipulating these special files, we can interact with the kernel.

However, the Devfs file system has some drawbacks: (1) such as an indeterminate device mapping, sometimes a device mapping device file may be different, for example, our USB flash drive may correspond to SDA may also correspond to SDB. (2) For example, there are not enough primary/secondary device numbers, which can become a problem when there are too many devices. (3) There are too many files in the/dev directory and cannot represent actual devices on the current system. (4) The name is not flexible enough to be arbitrarily specified.

After Linux2.6, the introduction of a new file system SYSFS, which is mounted in the/sys directory, like Devfs, it is also a virtual file system, is also used to manage the system's equipment, it is actually linked to the system of the device and the bus organized into a hierarchical file, User-space programs can also use this information to implement the interaction with the kernel, which is an intuitive response to the actual device tree on the current system, which is built through the Kobject subsystem, and when a kobject is created, the corresponding files and directory cards are built, located/ SYS directory, since each device has a unique directory in the SYSFS, then it can be read and written by the user space.

The tool udev for user space uses the information provided by SYSFS to implement all DEVFS functions, but the difference is that Udev is running in user space, and DEVFS is running in kernel space, and Udev does not exist devfs those congenital flaws. Therefore, SYSFS is the future direction of development.

Udev is a tool that can update device files based on the condition of the hardware devices in the system, including the creation, deletion, etc. of the device files. Device files are usually placed in the/dev directory, and after using Udev, only the devices that are actually present in the system are included under/dev. It is independent of the hardware platform, is located in the user space, requires kernel SYSFS and TMPFS support, SYSFS-bit udev provides the device entrance and Uevent channel, and TMPFS provides storage space for udev device files.

Udev works entirely in the user state, using the HotPlug event sent by the kernel when the device joins or removes it. Details about the device are output by the kernel to the Sysfs file system in/sys. All device naming policies, permissions control, and event handling are done in a user-state. But Devfs is part of the kernel that works.

  

Udev is used to manage/dev, not to load kernel drivers, so udev does not automatically load drivers when nonexistent nodes are opened. All devices in the system should generate HotPlug events, load appropriate drivers, and Udev will notice this and create a corresponding device node for it, and if you don't want all the device drivers to stay in memory, we should use something else to manage our modules, It is not the work of Udev. The method used by DEVFS has led to a large number of useless modprobe attempts to detect the presence of the device. Each exploratory test creates a new process that runs Modprobe, and almost all of this is useless.

The naming of DEVFS is not recommended and is not officially supported, because the way it uses a simple enumeration of devices is really a stupid way to be able to add or remove devices at any time. And these numbers give us only trouble, and they can't be used to determine the device.

When the kernel detects that a new device appears on the system, the kernel generates a new record for the device in the Sysfs file system, and the general Sysfs file system is mount to the/sys directory. A new record is represented as one or more files or directories, and each file contains specific information. Udev is UDEVD in the system as a daemon, which detects the presence of new devices in some way, and obtains some information about the device by locating records in the corresponding SYSFS of the device. Udev examines the files in this directory, based on the directory specified in the/etc/udev/udev.conf file Udev_rules, and the files in this directory are rules files that are intended to be implemented for a class or device. Udev reads files according to the ASCII alphabetical order of the filenames, and if Udev finds a rule that matches the newly added device, Udev configures the new device according to the actions defined by the rule. The subsequent rule files are not read at the same time.

As for Udev to maintain a uniform device name regardless of the order in which the devices are connected, Udev achieves this by adding aliases to the device names generated by the kernel. Udev is a user-mode program that does not change the behavior of the kernel. As a result, the kernel can still generate device names such as SDA, SDB, and so on. However, Udev can distinguish different devices according to other information of the device, such as bus information, such as buses, manufacturers, vendor, etc., and produce equipment files. Udev can solve this problem by simply taking a fixed file name for the device file. In subsequent operations on the device, simply refer to the new device name. However, in order to ensure maximum compatibility, the new device is always used as a symbolic link to the device name generated automatically by the kernel Laishui.

Sinsing analysis of Devfs, SYSFS, and Udev in Linux