Hubbry Logo
UdevUdevMain
Open search
Udev
Community hub
Udev
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Udev
Udev
Udev
View on Wikipedia
from Wikipedia
udev
DevelopersGreg Kroah-Hartman and Kay Sievers
Initial releaseNovember 2003; 22 years ago (2003-11)
Stable release
258.1[1] / 13 October 2025; 19 days ago (13 October 2025)
Repository
Written inC
Operating systemLinux
TypeDevice node
LicenseGPLv2
WebsiteOfficial website

udev (userspace /dev) is a device manager for the Linux kernel. As the successor of devfsd and hotplug, udev primarily manages device nodes in the /dev directory. At the same time, udev also handles all user space events raised when hardware devices are added into the system or removed from it, including firmware loading as required by certain devices. udev was developed by Greg Kroah-Hartman and Kay Sievers, with much help from Dan Stekloff, among others.

Rationale

[edit]

It is an operating system's kernel that is responsible for providing an abstract interface of the hardware to the rest of the software. Being a monolithic kernel, the Linux 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 through system calls or over their device nodes.

To be able to deal with peripheral devices that are hotplug-capable in a user-friendly way, a part of handling all of these hotplug-capable hardware devices was handed over from the kernel to a daemon running in user-space. Running in user space serves security and stability purposes.

Design

[edit]

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.

  • In case a new storage device is connected over USB, udevd is notified by the kernel and itself notifies the udisksd-daemon. That daemon could then mount the file systems.
  • In case a new Ethernet cable is plugged into the Ethernet NIC, udevd is notified by the kernel and itself notifies the NetworkManager-daemon. The NetworkManager-daemon could start dhclient for that NIC, or configure according to some manual configuration.

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 join wireless networks only if they are logged into the video console). Application authors resorted to using setuid binaries or run service daemons 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.

Overview

[edit]

Unlike traditional Unix systems, where the device 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. Although devfs used to provide similar functionality, Greg Kroah-Hartman cited a number of reasons[4] for preferring udev over devfs:

  • udev supports persistent device naming, which does not depend on, for example, the order in which the devices are plugged into the system. The default udev setup provides persistent names for storage devices. Any hard disk is recognized by its unique filesystem id, the name of the disk and the physical location on the hardware it is connected to.
  • udev executes entirely in user space, as opposed to devfs's kernel space. One consequence is that udev moved the naming policy out of the kernel and can run arbitrary programs to compose a name for the device from the device's properties, before the node is created; there, the whole process is also interruptible and it runs with a lower priority.

The udev, as a whole, is divided into three parts:

  • Library libudev that allows access to device information; it was incorporated into the systemd 183 software bundle.[5]
  • User space daemon udevd that manages the virtual /dev.
  • Administrative command-line utility udevadm for diagnostics.

The system gets calls from the kernel via netlink socket. Earlier versions used hotplug, adding a link to themselves in /etc/hotplug.d/default with this purpose.

Operation

[edit]
udev has been incorporated into systemd 183[5]

udev is a generic device manager running as a daemon on a Linux system and listening (via a netlink 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 to HAL, 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 the D-Bus IPC system to all interested processes. In this way, desktops such as GNOME or K Desktop Environment 3 could start the file browser to browse the file systems of newly attached USB flash drives and SD cards.[6]

By the middle of 2011 HAL had been deprecated by most Linux distributions as well as by the KDE, GNOME[7] and Xfce[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 and upower.

  • udev provides low-level access to the linux device tree. Allows programs to enumerate devices and their properties and get notifications when devices come and go.
  • dbus is a framework to allow programs to communicate with each other, securely, reliably, and with a high-level object-oriented programming interface.
  • udisks (formerly known as DeviceKit-disks) is a daemon that sits on top of libudev and other kernel interfaces and provides a high-level interface to storage devices and is accessible via dbus to applications.
  • upower (formerly known as DeviceKit-power) is a daemon that sits on top of libudev and other kernel interfaces and provides a high-level interface to power management and is accessible via dbus to applications.
  • NetworkManager is a daemon that sits on top of libudev and other kernel interfaces (and a couple of other daemons) and provides a high-level interface to network configuration and setup and is accessible via dbus to apps.[9]

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.

History

[edit]

udev was introduced in Linux 2.5. The Linux kernel version 2.6.13 introduced or updated a new version of the uevent 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's codebase was merged into the systemd source tree, making systemd 183 the first version to include udev.[5][10][11] In October 2012, Linus Torvalds criticized Kay Sievers's approach to udev maintenance and bug fixing related to firmware 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, we revert 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, the Gentoo Linux project created a fork of systemd's udev codebase in order to avoid dependency on the systemd architecture. The resulting fork is called eudev and it makes udev functionality available without systemd. A stated goal of the project is to keep eudev independent of any Linux distribution or init 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 as OpenRC and Upstart, 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 until kdbus 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]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Udev

View on Grokipedia
from Grokipedia
Udev, short for "userspace /dev", is a device manager for the that dynamically handles the creation, removal, and management of device nodes in the /dev directory by responding to kernel events known as uevents. It provides consistent device naming, permission management, and symlink creation to ensure reliable access to hardware components such as storage drives, network interfaces, and input devices. As a userspace daemon, udev replaces earlier mechanisms like devfs and hotplug, enabling hotplug support for removable devices and automatic loading of kernel modules based on hardware detection. Originally developed as part of the 2.6 kernel series to address limitations in static device management and race conditions in devfs—introduced in 2000 and deprecated by 2006—udev leverages the filesystem to expose detailed hardware information to userspace processes. It processes rules defined in configuration files, typically located in directories like /etc/udev/rules.d and /usr/lib/udev/rules.d, to customize device handling, such as renaming network interfaces for predictability or setting ownership for specific users. This rule-based system allows system administrators to tailor device behavior without kernel modifications, supporting a wide range of hardware from USB peripherals to PCI devices. In most contemporary distributions that use , udev is integrated as the systemd-udevd service, which runs early in the boot process to populate the /dev directory using the in-memory devtmpfs filesystem for efficiency. Standalone forks such as eudev exist for distributions avoiding integration. This integration ensures seamless coordination with other components, such as handling module autoloading via and broadcasting events to subscribers for further processing. Udev's design emphasizes performance and flexibility, minimizing disk I/O by maintaining device information in a database and supporting features like persistent device identification across reboots.

Introduction

Definition and Purpose

Udev is a userspace for the that dynamically creates, removes, and renames device nodes in the /dev directory in response to kernel events. It operates as a daemon, listening for uevents from the kernel via a socket, which notify the system of hardware additions, removals, or state changes. This allows udev to populate /dev with appropriate device files, including numbers, based on device attributes exposed through . The primary purpose of udev is to provide a flexible, policy-driven solution for device detection, persistent naming, and event-triggered actions, succeeding earlier mechanisms like devfs and the hotplug subsystem. Unlike devfs, which handled device management within the kernel and suffered from limitations such as inflexible naming policies and inability to customize behavior without kernel modifications, udev shifts this logic to userspace for greater configurability. It also addresses issues in static /dev population methods, like race conditions during boot-time device enumeration and the need for predefined device files that may not match runtime hardware. By bridging the kernel's hardware abstraction layer—via uevents and —with userspace applications, udev enables advanced features such as automatic filesystem mounting, permission management for device nodes, and the creation of symbolic links for consistent device identification across reboots or hardware changes. This userspace approach supports hotplugging of peripherals like USB devices and network interfaces, ensuring seamless integration without requiring kernel recompilation or static configurations.

Key Components

The key components of udev form a cohesive system for managing device events in Linux userspace. At its core is the udevd daemon, which operates as a background process to handle incoming device notifications from the kernel. Complementing this are the libudev library for programmatic access to device information and the udevadm utility for administrative tasks. These elements work together to ensure dynamic device management without kernel modifications. The udevd daemon, implemented as the systemd-udevd.service unit, listens for uevents from the kernel—such as device additions, removals, or state changes—and processes them by matching against rules to manage device nodes, permissions, symlinks, and network interface names. It maintains an internal database of device properties derived from attributes and uevent data, enabling efficient handling of hardware events. Libudev serves as the programmatic interface to udev's functionality, offering an for applications to enumerate, query, and monitor local devices through functions like udev_enumerate_new() for listing devices and udev_monitor_new_from_netlink() for event subscriptions. Although deprecated in favor of the sd-device in modern versions, libudev remains available for legacy compatibility and provides access to the udev database populated by udevd. The udevadm command-line tool facilitates interaction with udev for testing, , and control, supporting operations such as querying device information with udevadm info, triggering kernel events via udevadm trigger, monitoring uevents with udevadm monitor, and simulating rule processing through udevadm test. It interfaces directly with the udevd daemon and the udev database to inspect or manipulate runtime behavior without requiring root privileges for read-only queries. Since its integration into in 2012, these components—udevd, libudev, and udevadm—have been bundled as part of the package, with udevd specifically renamed to systemd-udevd while preserving the traditional udev naming conventions for compatibility. In operation, udevd relies internally on libudev for device object management during event processing, while udevadm leverages libudev to query the database and communicate with udevd; for instance, udevd receives kernel uevents via a netlink socket, processes them using libudev structures, and exposes results accessible via udevadm. This modular design allows applications to interact seamlessly with hardware changes managed by the daemon.

Design and Architecture

Core Principles

Udev operates entirely in userspace, enabling dynamic management of device nodes in the /dev directory without requiring kernel recompilation or modifications, which prevents kernel bloat and enhances system flexibility. This design allows administrators to customize device handling through scripts and rules, leveraging kernel-provided interfaces like for device information and sockets for event notifications, rather than embedding such logic directly into the kernel. At its core, udev employs an event-driven model that responds to kernel-generated uevents in real time, ensuring immediate handling of device additions, removals, or changes without polling. These events, triggered by hardware hotplug activities such as USB insertions or PCI card additions, allow udev to create or remove device files on demand, supporting efficient management of dynamic hardware environments. As a successor to devfs and hotplug, this approach builds on prior mechanisms but shifts the complexity to userspace for greater maintainability. Persistent device naming is a foundational principle, achieved by associating stable identifiers—such as , bus topologies, or vendor-specific attributes—with device nodes to maintain consistent names across reboots and hardware reconfigurations. For instance, a USB device might be named based on its unique serial number rather than volatile kernel-assigned addresses, preventing issues like shifting disk labels that could disrupt system operations. Udev's architecture emphasizes modularity through the : device detection via , naming via configurable schemes, and action execution via external programs, promoting extensibility and integration with other tools. This division allows independent development of components like libsysfs for querying device properties and namedev for applying naming rules, facilitating adaptations for diverse hardware without monolithic changes. By focusing on hotplug events, udev efficiently populates /dev only as needed.

Event Processing Mechanism

The event processing mechanism in udev begins with the kernel's kobject subsystem, which generates uevents to notify userspace of device changes such as addition or removal. These uevents are transmitted from the kernel to userspace applications like the udev daemon (udevd) via sockets, a bidirectional communication channel between kernel and user space. Specifically, the kernel invokes functions like kobject_uevent() to broadcast events with an action type, such as KOBJ_ADD for device addition or KOBJ_REMOVE for removal, encapsulating device information for further processing. Upon reception, the udevd daemon, managed by the systemd-udevd.service, listens on the netlink socket for these multicast uevents and enqueues them for handling. Uevents are formatted as environment variables, including key details like ACTION=add or ACTION=remove to indicate the event type, alongside attributes such as DEVPATH (the sysfs path), SUBSYSTEM (the device category), and KERNEL (the kernel name for the device). This queue management ensures concurrent events are processed asynchronously without blocking the kernel; events lacking interdependencies—such as those for unrelated devices—execute in parallel, limited by configurable parameters like the maximum number of child processes to prevent resource exhaustion. Once enqueued, udevd matches incoming uevents against device attributes to identify and classify them precisely. Matching occurs by comparing event variables to criteria like subsystem names or specific attributes (e.g., ATTR{idVendor} for a device's ID), enabling targeted filtering before rule application. The overall flow proceeds as follows: the kernel detects a device change and sends the uevent via ; udevd receives and parses it, adding to the queue; attributes are evaluated for matching; and finally, suitable filters and rules are applied to determine subsequent actions. This architecture maintains efficient, non-blocking operation even under high event volumes, supporting dynamic device management in systems.

Operation

Device Event Handling

Udev handles device events by processing kernel-generated uevents for addition, removal, or changes to devices in the system, executing the appropriate operational steps to manage device nodes and related resources. These events are queued and processed by the udev daemon, which responds dynamically to maintain the /dev directory and inform other system components. For add events, udev first detects the new device through the incoming uevent, then creates the corresponding device node in /dev with permissions set based on configuration, establishes any specified symlinks, and executes programs if directed to do so. This sequence ensures the device becomes immediately accessible to user-space applications. Remove events trigger the opposite process: udev removes the device node from /dev, cleans up associated symlinks, updates its internal database, and notifies dependent services to handle the device's unavailability. This cleanup prevents stale references and allows graceful shutdown of related processes. Change events occur when a device's properties are modified, prompting udev to update attributes, adjust permissions, or rename nodes and symlinks as needed to reflect the new state. Such updates maintain consistency without full recreation or removal of the device node. Udev supports both synchronous and asynchronous modes for events, with defaults configured to prioritize speed through parallel execution over strict sequential ordering, allowing multiple events to be handled concurrently. Short-running tasks, such as node creation, execute synchronously, while longer operations may defer to external mechanisms. In case of errors during event processing, such as timeouts or failed operations, udev logs details via for debugging and employs fallback behaviors like default permissions or termination of worker processes after a configurable timeout (default 180 seconds). This ensures stability by preventing indefinite hangs and allowing recovery through standard kernel defaults.

Rule Application and Actions

When udev processes a device event, it evaluates rules sequentially from files in directories such as /lib/udev/rules.d, /run/udev/rules.d, /etc/udev/rules.d, and others, in lexical order based on filename. Files in /etc/udev/rules.d take precedence over those in other directories if names conflict. Each rule consists of match keys that test device attributes against the event, and if all matches succeed, the associated assignment keys are applied to configure the device. The matching process uses keys like SUBSYSTEM, which identifies the subsystem of the event device (e.g., "block" for storage devices), and ATTRS{filename}, which searches the device path upward through parent devices for sysfs attributes matching specified values. All ATTRS keys in a rule must match attributes from the same device in the hierarchy. Operators such as == for exact equality and != for inequality or absence refine these matches, allowing precise filtering of events like device addition or removal. The IMPORT key further enhances matching by pulling in additional properties, such as from parent devices or external programs, to import variables into the device's environment for subsequent evaluation. Upon a successful match, udev executes actions defined by assignment keys. The SYMLINK key creates symbolic links to the device node, enabling user-friendly naming (e.g., linking a USB drive to /dev/disk/by-id/usb-...), with multiple links separated by spaces and higher-priority links overriding others via the link_priority attribute. Permissions are set using GROUP to assign a group ownership and OWNER to specify a user, ensuring secure access to the node. For dynamic behaviors, the RUN key invokes external programs or built-ins after all rules are processed, such as running a script to mount a USB drive. Programmatic actions leverage the environment populated during matching, where keys like ENV{key} set custom properties that are passed as variables to executed programs, allowing scripts to access device details like serial numbers or paths. These programs run asynchronously unless specified otherwise, integrating with broader system tasks while inheriting the event's context. In cases of multiple matching rules for the same device, later rules in the sequence override earlier ones for assignments like symlinks or environment variables, unless a final assignment operator (:=) is used to lock a value permanently. This resolution ensures consistent device configuration without ambiguity.

Configuration and Customization

Rules and Configuration Files

Udev's configuration relies on a hierarchical system of rule files and a primary daemon configuration file to define how device events are handled. The rule files are organized in specific directories, with system-provided defaults located in /usr/lib/udev/rules.d/ and local administrator customizations placed in /etc/udev/rules.d/, where the latter directory takes precedence to allow overrides without modifying system files. Additional directories such as /run/udev/rules.d/ for runtime changes and /usr/local/lib/udev/rules.d/ may also be used, but files are processed in priority order from /etc/ to lower-priority locations. Rule files must end with the .rules extension to be recognized; others are ignored. They are read and applied in lexical (alphabetical) order across all directories, ensuring predictable processing. Empty lines are skipped, and lines beginning with # serve as comments, facilitating maintenance without affecting rule evaluation. The syntax of rules is token-based, consisting of comma-separated expressions that include match keys for device attributes and operators for assignments or actions. For instance, a match key like KERNEL=="sd*" identifies block storage devices starting with "sd", while assignment operators such as = or := set properties, as in NAME="%k" to assign the kernel device name to the symlink. Other operators include += for appending to lists and -= for removal, enabling flexible device naming and property management. The daemon's behavior is configured via /etc/udev/udev.conf, which supports overrides in /run/udev/udev.conf or system directories like /usr/lib/udev/udev.conf. Key options include udev_log to set the logging verbosity (e.g., "info" or "debug"), children_max to limit concurrent event processing (defaulting to system resource limits if set to 0), and event_timeout to define the wait period for subsystem replies (default 180 seconds). For testing and validation, the udevadm test command simulates a device event on a specified path (e.g., a entry), outputting the matched rules, applied assignments, and any actions like RUN program executions, helping administrators debug configurations without live system changes.

Advanced Customization Options

Udev supports advanced customization through the use of environment variables within rules, enabling precise matching and assignment based on device properties. For instance, the ENV{ID_SERIAL} variable allows rules to reference a device's unique , facilitating persistent naming schemes that remain consistent across reboots regardless of detection order. This is particularly useful for storage devices or peripherals where predictable identifiers are essential for scripting or mounting. Environment variables can be matched using operators like == or assigned with = in rule files, expanding on basic syntax by incorporating dynamic device attributes from . Integration with the hardware database (hwdb) provides a centralized mechanism for mapping vendor and product identifiers to udev properties, stored in source files under /usr/lib/udev/hwdb.d/ and compiled into a binary database at /etc/udev/hwdb.bin. This database uses modalias-like keys, such as usb:v*p*d* for USB devices, to associate values like custom properties (e.g., EV_KEY=1 for input devices), allowing udev to automatically enrich device events with vendor-specific details without explicit rules. Administrators can extend the database by adding .hwdb files in /etc/udev/hwdb.d/, which override system defaults after recompilation with systemd-hwdb update, ensuring tailored mappings for niche hardware. Event inhibition offers control over udev's processing pipeline via OPTIONS directives in rules, such as ignore_device, which skips further handling of matching events to prevent unnecessary node creation or actions for irrelevant hardware. This is valuable for suppressing noise from virtual or duplicate devices, reducing system overhead during hotplug events. Similarly, ignore_remove discards subsequent removal notifications for specified devices, maintaining stability in dynamic environments. These options must be placed at the end of a rule to take effect after all prior matches and assignments. Udev leverages the MODALIAS environment variable, derived from device modalias strings in , to automate kernel module loading by invoking modprobe $MODALIAS for events carrying this key, ensuring drivers are bound promptly without manual intervention. This mechanism supports efficient autoloading for bus-specific hardware, such as USB or PCI devices, by matching aliases against available modules. However, udev's built-in firmware loading capability, which previously handled binary blobs via similar events, was deprecated and removed in 2014 to delegate this responsibility to the kernel. Debugging advanced configurations relies on tools like udevadm monitor, which captures real-time kernel uevents and post-rule udev events, outputting device paths and properties for tracing event flow. Invoked with options such as --kernel for raw uevents or --udev for processed ones, it aids in verifying rule triggers during device insertion or removal. Verbose logging can be enabled via the udev_log setting in /etc/udev/udev.conf at the debug level, directing detailed output to the system journal for analysis of rule evaluation and errors. The udevadm test command further simulates events on specific devices, displaying verbose processing steps when the --verbose flag is used.

Integration and Usage

Integration with Systemd

In 2012, the udev codebase was merged into the project with the release of version 183, renaming it to systemd-udev and unifying their build processes and dependencies. This integration eliminated the need for a separate standalone udev package, as future development and maintenance occur within the source tree. The merger provides tighter integration between device management and 's service architecture, enabling features like socket activation for the systemd-udevd daemon. Through sockets such as systemd-udevd-control.socket and systemd-udevd-kernel.socket, the daemon activates on demand in response to kernel events, reducing idle resource consumption and supporting parallel service startup during boot. Configuration for systemd-udev, including the main udev.conf file and rules in directories like /etc/udev/rules.d/ and /lib/udev/rules.d/, remains accessible via standard paths, ensuring seamless operation within environments. As of November 8, 2025, the latest stable systemd release, version 258.2, incorporates systemd-udev while preserving backward compatibility for existing udev rules and configurations. This component serves as the default device manager in major systemd-based Linux distributions, including Ubuntu and Fedora, facilitating consistent hotplug handling across these systems.[](https://docs.fedoraproject.org/en-US/fedora/latest/system-administrators-guide/kernel-module-and-hardware-discovery/

Interactions with Other System Tools

Udev interacts with other system tools primarily by supplying device events from the kernel, enabling dynamic management of hardware through user-space handlers. These interactions allow tools to respond to device additions, removals, or changes by executing rules that trigger services or adjust configurations. For instance, udev events can invoke commands or notify daemons, facilitating seamless integration in desktop and server environments. In disk management, udev triggers the udisks daemon (udisksd) by monitoring kernel uevents, which udisks uses to create objects representing block devices and drives. This enables automatic mounting and querying of storage devices in desktop environments like . Similarly, for network interfaces, relies on udev to detect and enumerate devices, applying configurations based on udev-supplied properties; administrators can use udev rules to make ignore specific interfaces, such as virtual or unmanaged ones. The deprecation of the Hardware Abstraction Layer (HAL) around 2010 marked a significant shift, with udev assuming direct responsibility for device event handling in user space. Post-2011, tools like BlueZ for Bluetooth management transitioned to using libudev directly for detecting and configuring devices, bypassing HAL's monolithic structure. This change improved efficiency and maintainability, as HAL's functionality was absorbed into udev and related libraries. As an alternative in resource-constrained environments, mdev from serves as a lightweight for embedded systems, handling basic /dev node creation via simple scripts. Unlike udev, which supports complex rule matching and actions for fine-grained control, mdev offers minimal overhead but lacks udev's richer syntax for attributes, subsystems, and programmatic responses. Udev facilitates change notifications to tools like GNOME's udisks2 by providing uevents that the udisks daemon processes and broadcasts via signals, such as InterfacesAdded or InterfacesRemoved on the org.freedesktop.UDisks2 service. This allows desktop applications to react promptly to storage events without direct kernel polling. Security in udev interactions emphasizes controlled access to /dev nodes, where rules set permissions using keys like OWNER, GROUP, and MODE to restrict read/write access based on user or group. RUN actions, which execute external programs after rule processing, pose risks if misconfigured, as they run with elevated privileges; to mitigate, udev enforces a sandbox prohibiting network access, filesystem mounts, or long-running daemons, with timeouts killing stalled processes. Administrators are advised to sandbox scripts further or prefer service unit integrations for persistent tasks.

History and Development

Early Development and Milestones

Udev originated in 2003 during the development of the 2.5 kernel, when and Kay Sievers created it as a userspace tool to manage hotplug events and dynamically populate the /dev directory, replacing kernel-based solutions like devfs. This initiative was driven by kernel developers' desire to shift device management policies—such as naming conventions and permissions—from the constrained kernel space to the more adaptable userspace environment, utilizing the virtual filesystem introduced in Linux 2.5 for accessing device attributes and hierarchies. The initial release occurred in May 2003 as a compact implementation, comprising about 6 KB of userspace code that mirrored devfs functionality while enabling customizable device handling through scripts and rules. A significant early was the presentation of udev at the Ottawa Linux Symposium in July 2003, where its architecture for event processing via sockets and support for persistent device naming based on stable hardware identifiers like serial numbers or bus locations was detailed. Subsequent releases in late 2003, such as version 011 in , refined event handling and integration with the hotplug mechanism, paving the way for broader testing and refinement. Persistent naming emerged as a foundational feature in these early versions, allowing consistent device node creation independent of kernel enumeration order, which addressed long-standing issues with volatile naming in dynamic environments like USB and PCI hotplug. By 2004–2005, udev had achieved maturation through widespread adoption in major distributions; for instance, Fedora Core 2 in May 2004 incorporated it as the standard device manager, deprecating devfs and emphasizing its role in enabling flexible, userspace-driven device policies. Version 125, released in 2008, marked another key milestone by optimizing performance through improved communication and reduced overhead in event processing, enhancing scalability for systems with high device churn.

Modern Evolution and Forks

In 2012, the udev project underwent a significant merger with , unifying its development under the systemd umbrella to streamline maintenance and integration within modern distributions. This integration, announced in April 2012, incorporated udev's source code into the systemd tree, allowing subsequent systemd releases to continue udev's versioning while benefiting from shared resources and parallel development. Several key deprecations followed this merger to refine udev's scope. Support for the Layer (HAL) was phased out by most distributions by mid-2011, as udev absorbed HAL's core functionalities for device event handling and property exposure, rendering the separate HAL daemon obsolete. Additionally, in May 2014, firmware loading capabilities were removed from udev, shifting this responsibility to the to avoid user-space interference in low-level operations. Recent updates in versions 250 and later (spanning 2022 to 2025) have focused on performance optimizations and enhanced usability. For instance, version 251 introduced prioritized subsystem triggering in udevadm for faster times by handling block and TPM devices early, while version 252 added input device prioritization to further accelerate initialization. Hardware database (hwdb) enhancements include new entries for signal analyzers, camera orientations, and network interface naming allowlists in versions 250 and 256, respectively, improving device identification efficiency. output support was added to tools like udevadm info and test in version 251, enabling structured data export for scripting and diagnostics. These changes, detailed in systemd's official , underscore ongoing refinements without altering udev's foundational architecture. Community responses to the systemd merger led to the creation of eudev, a fork initiated by Gentoo developers in November 2012 to provide an independent udev implementation decoupled from dependencies. Designed for non-systemd distributions like Gentoo and , eudev maintains compatibility with traditional init systems while preserving udev's core device management features, and it has been actively maintained as an alternative for users avoiding integration. As of 2025, udev remains the standard device manager in kernels across major distributions, with no major replacements emerging due to its entrenched role in dynamic /dev population and event handling.

Contributors

Primary Authors

initiated the development of udev in 2003 as a userspace tool to manage device events and replace the kernel-based devfs, focusing on leveraging for dynamic device node creation in /dev and driving the transition to userspace hotplug handling. With significant contributions from Dan Stekloff at , who helped shape the design, Kroah-Hartman authored the core udev daemon and related components like libsysfs, enabling flexible device naming policies outside the kernel. As a prominent developer at IBM's Linux Technology Center, he maintained udev until a handover around 2012. Kay Sievers emerged as a key contributor starting in 2006, enhancing udev's rule-based configuration system for device event processing and integration with userspace tools. He authored the libudev library, providing a stable for applications to query and monitor device events. Sievers led the merger of udev into in 2012, consolidating its development under the systemd project and advancing features like persistent device naming through refined rules and policies.

Ongoing Maintainers

The ongoing maintenance of udev is managed by the project, with primary oversight from lead developer . Contributions to udev components are driven by engineers from organizations such as , including key figures like Zbigniew Jędrzejewski-Szmek, who specializes in security and integration enhancements. The project's development occurs through the GitHub repository at systemd/systemd, where community members actively submit and review pull requests specifically for udev-related code. As of 2025, over 100 contributors have participated in systemd-udev updates across recent releases, with efforts centered on improving stability and support for containerized environments. Udev's governance follows the project's biannual stable release cycle, typically delivering major versions in spring and fall to ensure timely integration of fixes and features.

References

  1. https://www.freedesktop.org/software/systemd/man/udev.html
  2. https://man7.org/linux/man-pages/man7/udev.7.html
  3. https://www.linuxfromscratch.org/lfs/view/12.1/chapter09/udev.html
  4. https://docs.oracle.com/en/operating-systems/oracle-linux/8/udev/udev-AbouttheUdevDeviceManager.html
  5. https://documentation.suse.com/sles/12-SP5/html/SLES-all/cha-udev.html
  6. https://www.freedesktop.org/software/systemd/man/systemd-udevd.service.html
  7. https://www.kernel.org/doc/ols/2003/ols2003-pages-249-257.pdf
  8. https://www.kernel.org/doc/ols/2006/ols2006v2-pages-349-356.pdf
  9. https://www.freedesktop.org/software/systemd/man/udevadm.html
  10. https://lists.freedesktop.org/archives/systemd-devel/2012-July/006064.html
  11. https://landley.net/kdocs/ols/2003/ols2003-pages-249-257.pdf
  12. https://www.kernel.org/doc/html/latest/core-api/kobject.html
  13. https://www.man7.org/linux/man-pages/man7/udev.7.html
  14. https://www.freedesktop.org/software/systemd/man/latest/systemd-udevd.service.html
  15. https://man7.org/linux/man-pages/man8/systemd-udevd.8.html
  16. https://www.freedesktop.org/software/systemd/man/udev.conf.html
  17. https://linux.die.net/man/7/udev
  18. https://man7.org/linux/man-pages/man7/hwdb.7.html
  19. https://www.freedesktop.org/software/systemd/man/systemd-hwdb.html
  20. https://cgit.freedesktop.org/systemd/systemd/commit/?id=be2ea723b1d023b3d385d
  21. https://man7.org/linux/man-pages/man8/udevadm.8.html
  22. https://lwn.net/Articles/499480/
  23. https://lwn.net/Articles/490413/
  24. https://www.man7.org/linux/man-pages/man5/udev.conf.5.html
  25. https://github.com/systemd/systemd/releases/tag/v258.2
  26. https://storaged.org/doc/udisks2-api/latest/ref-daemon.html
  27. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/configuring-networkmanager-to-ignore-certain-devices_configuring-and-managing-networking
  28. https://people.freedesktop.org/~alanc/7.7-draft-ReleaseNotes.html
  29. https://cgit.freedesktop.org/systemd/systemd/commit/?id=3e2147858f21943d5f4a781c60f33ac22c6096ed
  30. https://docs.yoctoproject.org/dev/dev-manual/device-manager.html
  31. https://storaged.org/doc/udisks2-api/latest/gdbus-org.freedesktop.UDisks2.Block.html
  32. https://lwn.net/Articles/65197/
  33. https://lwn.net/Articles/64536/
  34. https://distrowatch.com/external/Fedora2-Release-Notes.html
  35. https://cloudfront.debian.net/debian-archive/debian/pool/main/u/udev/
  36. https://lwn.net/Articles/420774/
  37. https://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
  38. https://raw.githubusercontent.com/systemd/systemd/main/NEWS
  39. https://lwn.net/Articles/525770/
  40. https://wiki.archlinux.org/title/Udev
  41. https://wiki.debian.org/udev
  42. https://lwn.net/Articles/490592/
  43. https://www.heise.de/en/news/FOSDEM-25-Systemd-outlines-its-future-10267216.html
  44. https://www.redhat.com/en/authors/zbigniew-jedrzejewski-szmek
  45. https://packages.fedoraproject.org/pkgs/systemd/systemd-udev/fedora-rawhide.html
  46. https://github.com/systemd/systemd
  47. https://github.com/systemd/systemd/graphs/contributors
  48. https://www.phoronix.com/news/systemd-258
  49. https://www.theregister.com/2025/09/23/systemd_258_gnome_49/
Add your contribution
Related Hubs
User Avatar
No comments yet.