 | This article'slead sectionmay be too short to adequatelysummarize the key points. Please consider expanding the lead toprovide an accessible overview of all important aspects of the article.(November 2014) |
| Developer(s) | Greg Kroah-Hartman andKay Sievers |
|---|---|
| Initial release | November 2003; 21 years ago (2003-11) |
| Stable release | |
| Repository | |
| Written in | C |
| Operating system | Linux |
| Type | Device node |
| License | GPLv2 |
| Website | Official website |
udev (userspace/dev) is a device manager for theLinux kernel. As the successor ofdevfsd and hotplug, udev primarily managesdevice nodes in the/dev directory. At the same time, udev also handles alluser space events raised when hardware devices are added into the system or removed from it, includingfirmware loading as required by certain devices.
It is anoperating system'skernel that is responsible for providing an abstract interface of the hardware to the rest of the software. Being amonolithic kernel, theLinux kernel does exactly that:device drivers are part of the Linux kernel, and make up more than half of its source code.[2] Hardware can be accessed throughsystem calls or over theirdevice nodes.
To be able to deal with peripheral devices that arehotplug-capable in a user-friendly way, a part of handling all of these hotplug-capable hardware devices was handed over from the kernel to adaemon running in user-space. Running in user space serves security and stability purposes.
Device drivers are part of the Linux kernel, in which their primary functions include device discovery, detecting device state changes, and similar low-level hardware functions. After loading a device driver into memory from the kernel, detected events are sent out to the userspace daemon udevd. It is the device manager,udevd, that catches all of these events and then decides what shall happen next. For this,udevd has a very comprehensive set of configuration files, which can all be adjusted by the computer administrator, according to their needs.
The complexity of doing so forced application authors to re-implement hardware support logic. Some hardware devices also required privileged helper programs to prepare them for use. These often have to be invoked in ways that could be awkward to express with the Unix permissions model (for example, allowing users to joinwireless networks only if they are logged into the video console). Application authors resorted to usingsetuid binaries or run servicedaemons to provide their own access control and privilege separation, potentially introducing security holes each time.[3]
HAL was created to deal with these challenges, but is now deprecated in most Linux distributions, its functionality being replaced by udevd.
Unlike traditionalUnix systems, where thedevice nodes in the/dev directory have been a static set of files, the Linux udev device manager dynamically provides only the nodes for the devices actually present on a system. Althoughdevfs used to provide similar functionality,Greg Kroah-Hartman cited a number of reasons[4] for preferring udev over devfs:
The udev, as a whole, is divided into three parts:
The system gets calls from the kernel vianetlink socket. Earlier versions usedhotplug, adding a link to themselves in/etc/hotplug.d/default with this purpose.
udev is a generic device manager running as adaemon on a Linux system and listening (via anetlink socket) to uevents the kernel sends out if a new device is initialized or a device is removed from the system. The udev package comes with an extensive set of rules that match against exported values of the event and properties of the discovered device. A matching rule will possibly name and create a device node and run configured programs to set up and configure the device.
udev rules can match on properties like the kernel subsystem, the kernel device name, the physical location of the device, or properties like the device's serial number. Rules can also request information from external programs to name a device or specify a custom name that will always be the same, regardless of the order devices are discovered by the system.
In the past a common way to use udev on Linux systems was to let it send events through a socket toHAL, which would perform further device-specific actions. For example, HAL would notify other software running on the system that the new hardware had arrived by issuing a broadcast message on theD-BusIPC system to all interestedprocesses. In this way, desktops such asGNOME orK Desktop Environment 3 could start thefile browser to browse the file systems of newly attachedUSB flash drives andSD cards.[6]
By the middle of 2011 HAL had been deprecated by most Linux distributions as well as by the KDE, GNOME[7] andXfce[8] desktop environments, among others. The functionality previously embodied in HAL has been integrated into udev itself, or moved to separate software such as udisks andupower.
udev receives messages from the kernel, and passes them on to subsystem daemons such as Network Manager. Applications talk to Network Manager over D-Bus.
HAL is obsolete and only used by legacy code. Ubuntu 10.04 shipped without HAL. Initially a new daemon DeviceKit was planned to replace certain aspects of HAL, but in March 2009, DeviceKit was deprecated in favor of adding the same code to udev as a package: udev-extras, and some functions have now moved to udev proper.
udev was introduced inLinux 2.5. The Linux kernel version 2.6.13 introduced or updated a new version of theuevent interface. A system using a new version of udev will not boot with kernels older than 2.6.13 unless udev is disabled and a traditional/dev directory is used for device access.
In April 2012, udev'scodebase was merged into thesystemd source tree, making systemd 183 the first version to include udev.[5][10][11] In October 2012,Linus Torvalds criticizedKay Sievers's approach to udev maintenance and bug fixing related tofirmware loading, stating:[12]
Yes, doing it in the kernel is "more robust". But don't play games, and stop the lying. It's more robust because we have maintainers that care, and because we know that regressions are not something we can play fast and loose with. If something breaks, and we don't know what the right fix for that breakage is, werevert the thing that broke. So yes, we're clearly better off doing it in the kernel. Not because firmware loading cannot be done in user space. But simply because udev maintenance since Greg gave it up has gone downhill.
In 2012, theGentoo Linux project created afork of systemd's udev codebase in order to avoid dependency on the systemd architecture. The resulting fork is calledeudev and it makes udev functionality available without systemd. A stated goal of the project is to keep eudev independent of anyLinux distribution orinit system.[13] The Gentoo project describes eudev as follows:[14]
eudev is a fork of systemd-udev with the goal of obtaining better compatibility with existing software such asOpenRC andUpstart, older kernels, various toolchains and anything else required by users and various distributions.
On May 29, 2014, support for firmware loading through udev was dropped from systemd, as it has been decided that it is the kernel's task to load firmware.[15] Two days later,Lennart Poettering suggested this patch be postponed untilkdbus starts to be utilized by udev; at that point, the plan was to switch udev to use kdbus as the underlying messaging system, and to get rid of the userspace-to-userspace netlink-based transport.[16]
udev was developed byGreg Kroah-Hartman andKay Sievers, with much help fromDan Stekloff, among others.
