Linux Hardware Management Prepares for Liftoff
After years of conflicting implementations and frustrating shortcomings, Linux hardware management is prepped to leave the oxcart behind and reach for the stars.
The 2.6 Linux kernel has been one amazing roller-coaster ride of excellent new features and changes coming faster than you can say "git along now, little patchies." Hardware detection and management, and removable media management are probably the most obvious changes to users.
We're almost to the point of genuine seamless no-muss no-fuss Plug-and-Play. There is still room for a bit of polish, and device support is always an uphill battle in this senselessly Windows-centric land of ours, but the progress in just a few years is stunning. 2.6.0 was released on December 17, 2003, just a bit over three years ago. While poor old Vista was getting bogged down in endless meetings over minutiae like shutdown menu elements, the Linux kernel team was pounding pell-mell down the trail like a team of amped-up sled dogs.
There are a lot of different daemons and subsystems that cooperate to provide smooth device detection and management, but the primary players are:
- hotplug and coldplug
D-Bus can be thought of as a central communications mechanism between Linux applications. If you want to sound properly geeky, it's an IPC (Interprocess Communication Facilities) mechanism for sending and receiving messages. Linux used to rely on sockets, pipes, filesystems, and shared memory for communications between applications. It wasn't very efficient or flexible, and without a common base communications system it meant developers spent a lot of energy re-implementing the same thing in all manner of different ways.
Prior even to Linux's creation, some of the problems the Linux developers would eventually face were well known to developers. An industry consortium called OMG (Object Management Group) came up with CORBA (Common Object Request Broker Architecture) as a solution to the problem of applications interoperability, and apparently a host of other problems as well. Some time later, the KDE team invented DCOP (Desktop COmmunications Protocol). There were other attempts to create a standard message platform, and then along came the D-Bus, a Freedesktop.org project designed from the ground up to be the universal, standard messaging platform for the Linux and Unix desktop. (There is even a Windows port in the works, windbus.) D-Bus is used on most Linux distributions these days.
D-Bus supplies a global system daemon and per-user session daemons. Take a look in /etc/dbus-1 to see what applications are using D-Bus on your system. Some of the more common examples are HAL, udev, NetworkManager, CUPS, and Yum.
HAL, the Hardware Abstraction Layer, maintains a database of devices on your system. You can see this by running the lshal command, which spews forth much output:
$ lshal [...] udi = '/org/freedesktop/Hal/devices/pnp_PNP0303' info.udi = '/org/freedesktop/Hal/devices/pnp_PNP0303' ... linux.subsystem = 'pnp' (string) linux.hotplug_type = 1 (0x1) (int) info.product = 'IBM Enhanced (101/102-key, PS/2 mouse ... [...] Dumped 112 device(s) from the Global Device List. ------------------------------------------------You can play with lshal a bit by putting it in monitor mode:
$ lshal --monitor Start monitoring devicelist:Then plug in and remove devices to see what happens.
Perhaps you are wondering why we need HAL when we already have dmesg? HAL contains a lot more information about hardware than the kernel does. The kernel doesn't need to know all that stuff; it has other jobs to do. You saw how much data HAL holds on your devices. Where does it all come from? From querying the hardware, from the kernel, from various system files, and from information collected by your desktop. In a nutshell, anything on your system that needs hardware information simply asks HAL.
And now we come to the best-known player in our little drama, udev. udev gained notoriety for its dastardly deed of replacing devfs, and then growing and changing so quickly we poor users were left in a bewildered daze. udev took over everything – hard drives and CD drives, network interfaces, printers, scanners, removeable storage media, handheld devices- everything. udev manages /dev nodes, device names, permissions and modes. So in a short time we had to learn new ways of managing our hardware, and then unlearning that and figuring out yet newer ways. We lived, as the ancient curse says, in interesting times. udev was a moving target, and Linux distributions were shipping with barely-cooked implementations that required a lot of manual tweaking.
But at last the dust is settling and a measure of stability is returning, and udev is working more like it's intended to, which is to load drivers and firmware for coldplug devices, which are connected at boot, and hotplug devices, which are connected to a running system. You may remember the days of individual hotplug and coldplug packages- those are long gone, and have been assimilated into udev.
I haven't found the answer to the question of why, if HAL contains all essential data about hardware devices, does udev require fat text files full of hardware lists, such as /etc/udev/rules.d/45-libsane.rules and /etc/udev/rules.d/45-libgphoto2.rules? These things have hundreds of entries, but odds are you'll have to manually enter your own devices anyway. Perhaps a wise person will answer this question, and then I will share it.
You can follow along with udev's activities with the udevmonitor command:
# udevmonitor udevmonitor prints the received event from the kernel [UEVENT] and the event which udev sends out after rule processing [UDEV] UEVENT[1178004205.550995] remove@/class/scsi_disk/7:0:0:0 UDEV [1178004243.613899] add@/class/scsi_generic/sg1 UDEV [1178004243.774988] add@/block/sdb/sdb1
Now you have a pretty good idea of what it takes to make that little icon pop up on your desktop when you attach a new device to your system. GNOME has a nice "Removable Drives and Media" tool for managing all peripherals, including PDAs, keyboards and mice, printers, scanners, and CD/DVDs. Kubuntu's System Settings panel is a nice KDE implementation for doing the same thing. The good times for Linux are just beginning; I predict that during the next five years we're going to complete the transition from ox and cart to space shuttle.