1-hot-swappable time from kernel space to user space delivery process

http://blog.csdn.net/bingqingsuimeng/article/details/7922217

When you connect a removable device to the system, the following events occur sequentially in the background of the system:

The L kernel detects new hardware inserts and 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.

L UDEV This message to the HAL Daemon (Hald) after the corresponding device node has been created. Of course, Udev also have to make sure that the newly created device node can be accessed by ordinary users.

L hotplug This message to Hald after loading the corresponding kernel module.

L Hald that the new hardware has been formally approved by the HotPlug and Udev after the news. 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.

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

L Hald will monitor the CDROM itself and send the message of the CD tray to and from the Dbus.

L 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 will invoke the program to update the fstab, it does not actually do its own work on the Mount

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

L 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 called by HotPlug to respond to various hot-swappable events generated by the kernel, resulting in the insertion of corresponding 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.