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

Log in or register to write something here or to contact authors.