Plug 'n Play progress in Linux

by Andy Oram

Related link: 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.


How far is Linux from Plug 'n Play?