We've expanded our Linux news coverage and improved our search! Search for all things Linux across O'Reilly!

Plug 'n Play progress in Linux

		Print
		Email weblog link
		Discuss
		Blog this

Andy Oram
Jul. 29, 2004 10:32 AM
Permalink

URL: http://conferences.oreillynet.com/os2004/...

Kernel developer and author Robert Love wants to take all the fun out of Linux. Someday you won't have to specify /dev pathnames to utilities when installing new devices, or configure CUPS and download a driver to make a printer visible, or determine which application can read data from a consumer device (unless you choose to do it the old-fashioned way). Instead, when you plug in something, it will just work, OS X style.

Love aired some even more extravagant fantasies, but we'll stick to plug and play for now. One of the pleasures of hearing Love's talk is that he brought alive the details of kernel and userspace implementation for these features, a collection of interfaces known as Project Utopia. Back-to-back with a talk from freedesktop.org developer Havoc Pennington on the messaging component called D-BUS, Love showed how Linux will hopefully soon make the leap to the ordinary consumer.

Love's and Pennington's appearances also highlighted how the free software community is pulling together around Project Utopia. Love started working for Ximian around the time it was bought by Novell; Pennington works for Red Hat. Love has deep roots in the Linux community, Pennington among X developers.

The hardest parts of plug and play are actually implemented already: detecting a plugged-in device, figuring out what driver handles it, and loading that driver. Given that all this has been in the Linux kernel for some time, the rest of the key steps toward plug-and-play support are:

sysfs

This kernel subsystem creates a directory named /sys and populates it with pseudo-files (there's probably a fancy, formal term for that but I'm not going to waste search engine time on it) that contain all the information the kernel knows about every device on the system: memory size, addresses, USB information, and so forth. The sysfs facility is similar to the familiar /proc directory and is gradually replacing it.

HAL

This is a common industry term standing for "hardware abstraction layer." On Linux, it consults sysfs and presents the information about devices and memory in a structured form convenient for programs to query. (If I understand this right, the lower layer, sysfs, is visible through both an API and as human-readable text, while the upper layer, HAL, is visible only through an API. This seems a little odd.)

D-BUS

This has nothing to do with hardware buses, but just presents a publish-and-subscribe interface that lets programs be notified when devices are added and devices be automatically associated with programs. For instance, when you plug your digital camera into a USB port, a film editing program might pop up on the computer monitor. The publish-and-subscribe model is familiar to modern GUI programmers and in many other programming environments. In this model, the process being monitored sends messages indicating events that occur within the process, while processes who want to do the monitoring register themselves to receive these events through asynchronous notification.

D-BUS consists of two components:

• A library that implements the publication and registration.
• A daemon that listens for events from publishers and sends them to subscribers. Different users may want different tools to respond to events such as the plugging in of a consumer device. Therefore, one instance of the D-BUS daemon handles events that should be responded to on a system-wide basis, while multiple instances potentially run for each login session.

Desktop tools

These provide a convenient and appealing user interface to devices and events; an example is GNOME Volume Manager.

sysfs, HAL, and GNOME Volume Manager are implemented now; D-BUS is a work in progress. Another facility, hotplug, which lets the kernel handle devices when they are plugged in, is also implemented now. (I did not attend a related relevant talk today, Greg Kroah-Hartman's session on udev.)

Another sort of internals was the subject of another session at the conference today: Brian Aker's "Building Your Own Storage Engine for MySQL." The talk was a tribute to MySQL's clean, modular design and carefully thought-out interfaces. The very existence of multiple storage engines shows MySQL's adaptability to different needs; it's quite impressive to learn on top of this that users can reasonably expect to be able to create their own storage engines--and in fact that some users seem to find this useful in order to accommodate legacy data with particular needs.

Andy Oram is an editor for O'Reilly Media, specializing in Linux and free software books, and a member of Computer Professionals for Social Responsibility. His web site is www.praxagora.com/andyo.

Return to weblogs.oreilly.com.