"A hardware abstraction layer (HAL) is an abstraction layer, implemented in software, between the physical hardware of a computer and the software that runs on that computer. Its function is to hide differences in hardware from most of the operating system kernel, so that most of the kernel-mode code does not need to be changed to run on systems with different hardware. A HAL allows instructions from higher level computer languages to communicate with lower level components, such as directly with hardware." -- 
"D-Bus is a system for interprocess communication (IPC)." -- 
"D-Bus allows other programs to register on it for offering services to others. It also offers client programs the possibility to look up which services are available. Programs can also register as waiting for events of the kernel like hot swapping hardware." -- 
First of all i'll introduce the idea of a device object. By definition it is the smallest addressable unit of a hardware. To put it in a simple form, HAL can create device objets to each function of a single hardware, like one for a webcam microphone and another to the embbeded camera constituing the webcam.
The linux HAL implementation represents each device as a device object and provides an API through D-BUS allowing asynchronous notifications about hardwares modifications, making system much more compatible to plug-and-lay devices. Specific applications (callouts) are invoked by the HAL daemon to ensure the right system policy over each device and then applications are ready to get the "address" of a device through HAL and then access it through kernel. Program can locate and issue generic devices operations also by using D-BUS to communication with the abstraction layer daemon.
Intended to only provide generic operations that apply to all devices, HAL is designed to integrate with libraries supporting specific devices operations. This way hardware manufacturers can develop their own hardware support (we now that is not a common fact in linux world).
The bus daemon tipically has multiple instances. One of them, called system channel, is high-privileged and responsible to deliver signals from HAL daemon to any process interested in them. The others are user instances intended to provide communication between applications in the user session and they are created one per user login session.
Designed to provide communication between desktop applications and between the desktop session and the operating system as shown above, D-Bus works by sending messages.
I'm not goin to cover this topic deeply as it would become technical and out of context. More information can be found at  and .
Basically udev is a userspace implementation of devfs. The /dev directory is huge and not all device files there match up to a physical device. It is also hard to keep the same device mapped to the same file like the usb problem: change usb interface for two usb printers and their corresponding /dev file will be changed, making it hard to always use the wanted hardware. This has changed with sysfs disposing device information under the /sys directory, but not solving the problem.
As a solution to the number of files listed in /dev was adopted the devfs. The concept is based on the fact kernel always knows what devices are present. This way, a ram based filesystem managed by the operating system heart is created and it shows only plugged devices.
Another problem is devfs forces device names and naming database into kernel memory and since it is not swapped out this causes an overhead when large amounts of devices are being used.
Looking for a solution for that problems, udev was intended to follow this standard:
1. Run in userspace
2. Create a dynamic /dev
3. Provice a consistent device naming
4. Provide a userspace API to access information about current system devices
The first item was achieved with /sbin/hotplug and sysfs and the other goals splitted udev in three subsystems:
1. namedev - handles all device naming
2. libsysfs - a standard libary for accessing device information on the system
3. udev - dynamic replacement for /dev
More information at  and .
Sorry about mispellings, i posted without a revision =P
Feel free to comment and give me suggestions.
Wednesday, August 30, 2006