Conceptual Understanding of Sysfs, Udev, Hald, Dbus
These daemons all build on one another to provide services that for a Linux operating system to allow user space applications to accesses and manage hardware and hardware related events. The rough dependency order of the services are:
- sysfs – system file system – exports hardware information to user space.
- udev – there appears to be no acronym for udev, but probably relates to user space dev, responsible for creating device nodes uder /dev
- hald – Hardware Abstraction Layer Daemon, provides services to the desktop,
- dbus – Desktop Bus, an interprocess communications mechanism,
As you move up the stack higher level services are provided, till you reach dbus which performs a lot of desktop inter process communication requirements besides just informing desktop applications of new hardware or changes in hardware status, such as passing information between applications like instance messenger status.
How Linux Exports Hardware Information From Kernel Space to User Space
A device driver is a kernel space program that allows user space applications to interact with the underlying hardware. Kernel space refers to privileged code which has full access to hardware and runs in ring 0 which is a hardware enforced privileged execution mode. User space applications run in a less privileged mode, ring 3, and cannot access hardware directly. User space application can only interact with hardware by making system calls to the kernel to perform actions on their behalf.
How the Sysfs Filesystem Works
The Linux kernel exports information about the devices from the device drivers to a pseudo filesystem mounted under /sys. This file system tells user space what devices are available. It is populated at system boot but when a hot plug device is inserted or removed the /sys file system is updated and the kernel fires events to let user space know that there has been a change.
One of these user space applications is the kernel device manager, udev, which creates a device node under the /dev directory to allow user space application access to the device. The name of the device node or file is determined by the device drivers naming convention or by user defined rules in /etc/udev/rules.d/. It is through the entries under /dev that user space application can interact with the device driver.
How Udev works
The udev daemon is also responsible for informing other user land applications of changes. The applications that are most important here are the HAL (hardware abstraction layer) daemon, and D-Bus (desktop bus). These applications are mainly used by desktop environment to carry out tasks when an event occurs such as open the file browser when a USB drive is inserted or image application when a camera is inserted.
How HALD and DBus work
While udev creates the relevant entries under the /dev file system if anything useful need to happen when the event occurs HAL and D-Bus are needed. (Note: HAL is now deprecated as it is being merged into udev). HAL is a single daemon responsible for discovering, enumerating and mediating access to most of the hardware on the host computer for desktop applications to which it provides a hardware abstraction layer. Application register with the D-Bus daemon to receive notifications of events and also post event notifications that other applications may be interested in. D-Bus is used for example to launch media players when a audio CD is inserted and to notify other applications of the currently playing song for example.