Talking about D-bus, UDEVD and Hald

The

D-bus is an IPC (inter-process communication, interprocess communication) mechanism optimized for the desktop environment, for interprocess communication or process and kernel communication. The most basic D-bus protocol is a one-to-one communication protocol. But in many cases, one side of the communication is the message bus. The message bus is a special application that communicates with multiple applications and passes messages between applications. Below we'll look at the role of the message bus in the example. The role of the message bus is somewhat similar to the window manager in the X system, which is both an X client and a management window.
D-bus-enabled systems have two standard message buses: System bus and session bus. The system bus is used for communication between system and application, and the session bus is used for communication between applications.
If the application uses Libdbus, it will be able to receive notification of hardware hot-swappable from the kernel, such as USB disk inserts and Pull-out. So, what kind of process has passed?
First, Udev the device event that registers the kernel through NetLink, and when a device is inserted/pulled out, Udev is notified that it will load the appropriate driver from the parameters in the event and the information in the SYSFS (or you can run the application by Hald to allow the user to choose the available driver) , create dev nodes so that the device is in a usable state.
Then, Dev sends the device insertion/removal event through socket:/org/freedesktop/hal/udev_event to Hald.
Then, Hald hangs on the socket:/org/freedesktop/hal/udev_event to wait for the event, and when an event occurs, it invokes the relevant function processing, which takes the primary parameter out of the event, creates a Hotplug_event object, Put it in the event queue, create a Device object, set the properties of the device, invoke the associated callouts, and then put it in the list of devices and trigger signal let Dbus notify the relevant application. If the device is pulled out, the associated callouts is invoked, then removed from the list of devices and triggered signal let Dbus notify the relevant application.

HAL (Hardware abstract lever) hardware abstraction. The Linux HAL runs in user space as a daemon process. Listen for a socket interface. Wait for Udev to send the notice. Udev for the device load drive, the device is available, often have udev rules, let udev notice Hald said equipment changes. Hal, as a database of hardware, records the properties of the hardware, what the current hardware is, what their properties are, and so on. Therefore, the user state program can query Hald to get the hardware information. You can also register a listener event on Hald. Hald will notify them when the monitoring hardware event occurs.

Description:
1, solid line arrows for active invocation, dashed arrows for the event escalation.
2, Udev through the NetLink register the kernel of device events, when a device inserted/extracted, Udev will be notified, it will be from the event with the parameters and SYSFS information, load the appropriate driver, create dev under the node, so that the device is in the available state.
3, Udev is only a framework, its behavior is completely controlled by its rules, these rules are stored in the directory/etc/udev/rules.d/, where 90-hal.rules is used to allow udev to insert/unplug the device through socket:/org/ Freedesktop/hal/udev_event forwarded to the HAL.
4, the HAL hangs on the socket:/org/freedesktop/hal/udev_event waits for the event, has the event to call the function Hald_udev_data processing, it first takes out the main parameter from the event, creates a hotplug_event object, put it into the event queue, and then call Hotplug_event_process_queue to handle the event.
5, Function Hotplug_event_begin is responsible for the handling of specific events, it divides all events into four categories, and deal with HOTPLUG_EVENT_BEGIN_SYSFS handling common equipment events, HOTPLUG_EVENT_BEGIN_ACPI processing ACPI events, HOTPLUG_EVENT_BEGIN_APM handling APM events, HOTPLUG_EVENT_BEGIN_PMU handling PMU events. It is to be noted that the event source of the latter three is not originated from Udev, but is triggered at Device_reprobe (osspec_device_reprobe/hotplug_reprobe_tree/hotplug_reprobe_ generate_add_events/acpi_generate_add_hotplug_event).
6. In function Hotplug_event_begin_sysfs, if you are inserting a device, create a Device object, set the properties of the device, call the associated callouts, and then put it in the device list and trigger signal to notify the relevant application. If the device is pulled out, the associated callouts is invoked, then removed from the list of devices and triggered signal let Dbus notify the relevant application.
7. The application can actively invoke the DBUS interface functions provided by the HAL, which are defined in libhal.h. The application can also register HAL's signal, and when the device changes, the HAL reports the event to the application by DBUS.
8, callout is a HAL an extension of the device, it in the insertion/removal of the execution. Can be specified in the Device information file (/usr/share/hal directory).
9, Addon is also HAL an extension of the way, it differs from the callout is that addon is often the trigger of the event, rather than the consumer of the event. The HAL's event source originates primarily from udev, and udev originates from kernel hotplug, while some devices, such as power devices, disk devices, and special keystrokes, do not produce hotplug events. HAL will not be notified, how to do, addon is used to support the new event source extension. For example, ADDON-ACPI receives an event from/proc/acpi/event or/var/run/acpid.socket and forwards it as a HAL event. Addon-storage detects the status of a disc or disk and sets the properties of the device. Addon-keyboard detects some special keystrokes and triggers the corresponding events.
(Access-check/ci-tracker/ck-tracker is responsible for the inspection of the Authority, which refers to the policykit/consolekit is not too familiar, have time to see.) ）
Simply put, the HAL is a device database that manages all the devices in the current system, you can query these devices in a variety of ways, you can get the characteristics of a specific device, and you can register device change events.

the function of the HAL:
1. Gets the list of devices of the specified type.
2. Get/Change the property value of the device.
3. Obtain the capability description of the equipment.
4. When the device is plugged in/removed, notify the relevant application.
5, when the device properties or capabilities change, notify the relevant application.

Reference articles:
"1" http://www.linuxidc.com/Linux/2011-01/31238.htm
"2" http://blog.csdn.net/faithsws/article/details/5380710