The udev device management framework is one of the new features that was added to the Linux 2.6 kernel, and allows the /dev namespace to be populated based on hotplug events sent from the kernel to the userspace udevd daemon. While reading through the udev FAQ, I found a good explanation of udev:
Q: How is udev related to devfs? A: udev works entirely in userspace, using hotplug events the kernel sends whenever a device is added or removed from the kernel. Details about the devices are exported by the kernel to the sysfs filesystem at /sys All device naming policy permission control and event handling is done in userspace. devfs is operated from within the kernel.
As well as some comedic writing:
Q: But udev will not automatically load a driver if a /dev node is opened when it is not present like devfs will do. A: Right, but Linux is supposed to load a module when a device is discovered not to load a module when it's accessed. Q: Oh come on, pretty please. It can't be that hard to do. A: Such a functionality isn't needed on a properly configured system. All devices present on the system should generate hotplug events, loading the appropriate driver, and udev will notice and create the appropriate device node. If you don't want to keep all drivers for your hardware in memory, then use something else to manage your modules (scripts, modules.conf, etc.) This is not a task for udev. Q: But I love that feature of devfs, please? A: The devfs approach caused a lot of spurious modprobe attempts as programs probed to see if devices were present or not. Every probe attempt created a process to run modprobe, almost all of which were spurious.
This made me laugh silly, and I wish more FAQ maintainers used this style of writing. Whoever wrote this, I commend you!