Linux Hot Plug processing mechanism series __linux

When you connect a removable device to the system, the following events occur sequentially in the background of the system:
The kernel detects new hardware inserts, and then notifies HotPlug and Udev separately. The former is used to load the corresponding kernel modules (such as Usb-storage), which are used to create the appropriate device nodes (such as/dev/sda1) in/dev.
After the Udev has created the appropriate device node, the message is notified to the HAL Daemon (Hald). Of course, Udev also have to make sure that the newly created device node can be accessed by ordinary users.
HotPlug the corresponding kernel module, the message is notified to Hald.
Hald the news from HotPlug and udev that the new hardware has been formally approved by the system. At this point it passes through a series of well-written rules files (the legendary XXX-POLICY.FDI), sending messages that discover new hardware through Dbus, and also calls Update-fstab or Fstab-sync to update/etc/fstab. Create the appropriate mount point for the appropriate device node.
The volume manager listens for messages found in the Dbus for new hardware. Depending on the hardware you insert (distinguishing between a U disk and a digital camera), the volume manager mounts the appropriate device nodes to the mount point created by Hald before opening a different application.


Of course, if you insert a disc in CDROM, the process may be simpler. Because the CDROM itself is a fixed hardware without the assistance of HotPlug and Udev:
Hald will monitor the CDROM itself, and the message will be sent through the dbus of the disc tray.
The volume Manager is responsible for checking the contents of the Platters in the CDROM, mounting them, and invoking the appropriate application.


Note that the Hald's job is to get the hardware-ready message upstream, and then forward the message to Dbus. Although it invokes the program to update the fstab, it does not actually do the work on the mount itself.






The following are the modules and tools involved in the above process:
HotPlug


The HotPlug package is not the same as the HotPlug module in the kernel, and the Pci_hotplug.ko in the 2.6 kernel is a kernel module, and the HotPlug package is used to handle the HotPlug events generated by the kernel. The package also detects existing hardware at boot time and loads the associated modules in the running kernel.




Not only hot plug, but also cold pluging. Hot-swappable occurs after the kernel starts, and cold pluging occurs during kernel startup.




/etc/hotplug/*.rc These scripts are used for cold plugging (detecting and activating hardware that already exists at system startup). They are called by the HotPlug initialization script. The *.rc script attempts to recover the hot-plug event that was lost while booting the system, for example, the kernel did not mount the root file system.




/etc/hotplug/*.agent These scripts will be hotplug
Called to respond to various hot-swappable events generated by the kernel, resulting in the insertion of the appropriate kernel modules and the invocation of user-predefined scripts.




The/sbin/hotplug kernel invokes this script by default when certain things in the kernel state change, such as hardware insertions and unplugging.




The subsystem for sending hot-swappable events (subsystem) includes the bus driver (USB, PCI, etc.) and the abstraction layer of some devices (network interface, disk partition, etc.). They are identified by the first parameter of the/sbin/hotplug.




For device drivers, you need to set up module_device_table in your code, pointing to a list of device IDs for devices that are of interest to the driver.


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.
HAL


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




L
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!




L
Some 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 are available for the plugged in USB device