Linux hot-swappable processing mechanism __linux

First, Udev

In the 2.6 kernel, Udev is used to replace the hotplug. According to Udev's author, Greg K.H, the reason for the hotplug is SYSFS, which produces a lot of hotplug events, far exceeding the 2.4 kernel (as long as the device driver that implements the Kobject model generates the event). So hotplug gets complicated, and because HotPlug is written by bash, it starts to become inefficient. So there was a project called Hotplug-ng, which was meant to solve the problem of being too complicated and inefficient, and Ng was supposed to be next generation. But the project has so far been incompetent, so Udev came forward and acted as a fireman.

After 2.6.15, the/proc/sys/kernel/hotplug will be empty, because the kernel notifies the user that the interface to the space becomes netlink, so the newest udev also uses the NetLink interface to write, discarding/sbin/hotplug or/sbin /udevsend. Udev can listen to device events directly on the 2.6.15 kernel after NetLink, SYSFS provides uevent file, "write" to the file can send out device events.

Udev works entirely in User state (userspace), using the HotPlug events (event) sent by the kernel when the device is added or removed. Detailed information about the device is from kernel output (export) to the Sysfs file system located in/sys. All device naming policies, permission controls, and event handling are done in user state. Devfs, in contrast, works as part of the kernel.

Traditionally Linux systems use the method of creating static devices, so a large number of device nodes (sometimes thousands of nodes) are created in the/dev directory, regardless of whether the corresponding hardware device actually exists. This is usually done by the Makedev script, which contains many commands to invoke the Mknod program, creating the corresponding primary and secondary number for each device that may exist in the world. When using the Udev method, only devices detected by the kernel will create device nodes for them. Because these device nodes are re-created every time the system starts, they are stored on the Tmpfs file system, the device node does not require a lot of disk space, and the memory consumed can be negligible.

The udev initialization script is responsible for creating a device node at Linux startup, which first registers the/sbin/udevsend as a hot-swappable event handler. Hot-swappable events (which will then be discussed) should not have occurred at this stage, registered Udev just in case. The Udevstart then traverses the/sys file system and creates a device that conforms to the description in the/dev directory . For example, the/sys/class/tty/vcs/dev contains a "7:0" string, and Udevstart creates a/DEV/VCS device with the main device number 7 and the secondary device number 0 based on this string. The name and permissions of each device created by Udevstart are set by the rules specified by the files in the/etc/udev/rules.d/directory. If Udev cannot find the permission file for the device you are creating, set its permissions to the default of 660, and the owner is root:root. Once the above steps are complete, the devices that already exist and are built into the drive are ready to use.

For module-driven devices, when the kernel detects a new device connection, the kernel produces a hot-swappable event and finds the user-space program for processing device connections in the/proc/sys/kernel/hotplug file (new kernel notification interface changes,/proc/sys/ Kernel/hotplug is empty). Udev
The initialization script will Udevsend
Registers as the handler. When a hot plug event is generated, the kernel lets Udev detect information about the new device in the/sys file system and create the project in/dev for the new device.

All devices displayed in Sysfs can be created by Udev to create nodes. If additional device support is added to the kernel, Udev can also automatically work for them.

Most Linux distributions handle module loading through the/etc/modules.conf configuration file, and access to a device node results in the corresponding kernel modules being loaded. This method does not work for Udev, because the device node does not exist until the module is loaded. Linux is designed to load a module when the device is found, not when it is accessed. By adding the module name to the /etc/sysconfig/modules file, the modules can be loaded at the time the system is started, so that the udev
You can detect the device and create the appropriate device node.

How to write Udev rules. Use the Udevinfo program to find items that can be used as matches in the rules file. There are two situations: the first is that when you insert the device into the system, the system generates a device name (such as/DEV/SDA) for the device. In that case, you first use the Udevinfo-q path-n/DEV/SDA, and the command produces a path that corresponds to the device name under SYSFS, such as/BLOCK/SDA. Then, when you use Udevinfo-a-P/SYS/BLOCK/SDA, the command displays a bunch of information, and the information is divided into chunks. This information actually comes from the SYSFS linked list maintained by the operating system, and the different blocks correspond to different paths. You can use this information as a match in the Udev rule file. However, it should be noted that the same rule can only use the information displayed in the same piece, can not write rules across blocks; the second situation is, do not know the system generated device name, it is only to the/sys directory down directory search, repeated use of Udevinfo-a-p/sys/path ... This command looks at the information, if the corresponding information is this device, then congratulations to you. Otherwise, change the directory again. Of course, in this case, the likelihood of success is relatively small.

Two, HAL

The HAL is located between the device driver and the application.

Third, D-bus

D-bus is a promising message bus and active system that is beginning to penetrate deeply into the Linux desktop. D-bus is essentially an implementation of interprocess communication (inter-process communication) (IPC), designed for desktop applications and OS communications.

A typical D-bus setting will consist of several buses. A persistent system bus, which is started when booting. This bus is used by the operating system and background processes, and is very secure so that any application cannot spoof system events. There will also be a number of session bus sessions buses, which are owned by the user when the user logs on and starts.

A more interesting but not practical example is the combination of jamboree and ringaling. Jamboree is a simple music player that has a d-bus interface so that it can be told to play, to the next song, to change the volume, and so on. Ringaling is a small program that opens/DEV/TTYS0 (a serial port) and observes what is received. When Ringaling finds the text "ring", it tells Jamboree to reduce the volume by D-bus. The end result is that if a modem is plugged into your computer and the phone rings, the music volume decreases for you.
That's what computers are after!
four or one tools for viewing hardware information

Lspci
Lists all PCI devices. There are two parameters that are more commonly used, and the-B and-v,lspci will also list the USB connectors.

Lshal Lists the system hardware devices.

Usbmodules
Lists the drive modules that can be used to insert a USB device.