udev is a userspace device manager for Linux 2.6 kernels. It
is used by most major distributions, with its predecessor devfs no longer
being available as of Linux 2.6.13. It was created by Greg Kroah-Hartman and
is freely available under the GNU General Public License.
So what the heck is a userspace device manager?
On Unix-like systems, access to most hardware is done via special files
called device nodes. By tradition, these device nodes live under the /dev
filesystem.
In the early days, /dev would be on a normal filesystem, and would be
populated as part of the base system install. There would be a lot of entries in
there — even though your system may not have twenty SCSI disks
with eight partitions on each, someone else's probably would. So, device nodes
were made for everything that might be available on someone's system.
Attempting to access one of these nodes would result in an error (often
ENODEV).
Clearly, this isn't particularly ideal. Not only do device nodes take up
space and inodes, they also make things harder for the system administrator.
With device names like /dev/sdc7 (or on some Unix variants,
/dev/ad2s1g), it's very easy to make a typo.
One solution to this problem, used by Linux 2.4 and
FreeBSD 5, is to make /dev a special filesystem known as devfs
that is managed by the kernel. The kernel can automatically create and remove
device nodes to correspond to the available hardware.
This is okay, but a userspace solution is even better. Rather than relying
upon the kernel to manage things, why not let the kernel send messages (say, via the
hotplug interface) to a normal program and have that program do the creating?
After all, devices are just special files that can be created using mknod.
This is how udev works.
But why move to userspace? What do we gain from an additional level of
indirection?
The main advantage is flexibility. As well as supporting the traditional
device naming scheme, udev can be configured to create arbitrarily
named devices. Rules can be made that create device nodes based upon the
device's type, its location, its serial number, its manufacturer or any other
property which is exported via the sysfs interface.
The canonical example of this involves desktop users. Maybe you have a digital camera,
a USB portable storage device and an MP3 player. Chances are, you disconnect and
reconnect these fairly regularly. With a traditional setup, the device to device
node mapping would be arbitrary and based upon the order in which you plugged
devices in; detach a device and reattach it and it may get a different name.
With udev, you can have your camera at /dev/camera,
your USB drive at /dev/usbdrive and your MP3 player at
/dev/sweetsweetmusic — and all this can be configured
without needing to touch the kernel or even reboot.
With a little help from device serial numbers, it's even possible to purchase two identical
external CD writers, paint one of them blue, and have a
/dev/cdwriters/blue and a /dev/cdwriters/beige, no
matter where or in what order the devices are plugged in.
There's also the issue of cleanliness; udev requires far less to be handled by the kernel than devfs does. For end users, this means increased reliability — kernel code must worry about several additional complexities that userspace programs do not. devfs was infamous for having all kinds of race conditions that were simply too hard to fix — udev, on the other hand, is so small that your average code monkey can understand the whole thing within a few hours of first looking at it.
References:
udev FAQ, http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ