2.2 Udev, Dbus & Device Management (101.1)

2.2 Udev, Dbus & Device Management

Quick Summary: Dynamic device handling in modern Linux is managed by the systemd-udevd (or udevd) daemon. Operating in user space, udev listens for kernel hardware events (uevents) via netlink sockets, inspects the device properties in /sys, and dynamically creates or removes device nodes in /dev (devtmpfs). Administrators customize device naming, permissions, symlinks, and automated scripts via rule files in /etc/udev/rules.d/*.rules managed by the udevadm tool, while D-Bus provides system-wide inter-process communication for device state notifications.

1. Dynamic Device Management Architecture

In early Linux kernels, the /dev directory was a static block of thousands of pre-created special device files (MAKEDEV). Modern Linux utilizes devtmpfs managed by udev to present only the hardware that physically exists on the system.

The Lifecycle of a Hardware Event

1. Hardware Attachment: A physical device (e.g., a USB storage drive or NVMe disk) is connected to the bus.
2. Kernel Detection: The kernel detects the device, initializes low-level communication, and registers it in /sys (sysfs).
3. Uevent Generation: The kernel emits an asynchronous uevent (user event) over a netlink socket containing key-value pairs (action, devpath, subsystem).
4. Udev Daemon Processing: systemd-udevd receives the uevent and evaluates its rules in alphanumeric order.
5. Node & Link Creation: udevd creates the node in /dev (e.g., /dev/sdb1), assigns ownership and UNIX permissions, creates persistent symlinks (e.g., /dev/disk/by-uuid/..., /dev/disk/by-id/...), and triggers configured helper applications or D-Bus notifications.

2. Udev Rules Directories & Precedence

Udev reads rule definitions from three primary directories. Files with identical names in higher-priority directories completely override files in lower-priority directories.

Ordering Convention

Within any directory, rules files are processed in lexicographical (alphabetical) order based on their filename prefix:

• 10-local.rules is processed before 50-udev-default.rules.
• 99-custom.rules is processed last.

Exam Trap: If an administrator creates /etc/udev/rules.d/60-persistent-storage.rules, udevd will use that file instead of /lib/udev/rules.d/60-persistent-storage.rules. To disable a vendor-supplied rule completely, create an empty file or a symlink to /dev/null with the same name in /etc/udev/rules.d/.

3. Udev Rules Syntax: Match Keys vs. Assignment Keys

Udev rule lines consist of comma-separated Match Keys (conditions that must evaluate to true) and Assignment Keys (actions to perform when all match keys succeed).

Comparison Operators

• ==: Equals (Match condition)
• !=: Not equal to (Match condition)
• =: Assign value (overwrites any previous setting)
• +=: Append value to a list (e.g., adding symlinks or RUN scripts)
• :=: Final assignment (assigns value and prevents subsequent rules from modifying this key)

Standard Match Keys

Standard Assignment Keys

Real-World Rule Examples

# 1. Create a persistent symlink /dev/backup_disk and set group permissions for a specific USB disk
ACTION=="add", SUBSYSTEM=="block", ATTR{idVendor}=="0781", ATTR{idProduct}=="5581", SYMLINK+="backup_disk", GROUP="storage", MODE="0660"

# 2. Grant normal users access to a USB serial adapter for embedded development
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", MODE="0666", GROUP="dialout"

# 3. Trigger a backup script when a specific block partition with a given UUID is plugged in
ACTION=="add", SUBSYSTEM=="block", ENV{ID_FS_UUID}=="3a7c-89b1", RUN+="/usr/local/bin/auto_backup.sh %k"

Udev Format Specifiers (Substitutions):

• %k or $kernel: The kernel name for the device (e.g., sdb1).
• %n or $number: The device number (e.g., partition 1 of sdb1).
• %p or $devpath: The sysfs path of the device.
• %%: A literal % character.

4. Administrative Device Utilities: udevadm

udevadm is the comprehensive administration tool for inspecting the udev database, walking the sysfs tree, monitoring real-time kernel uevents, and testing or reloading rules.

1. udevadm info (Device Inspection)

Used to query the udev database for device properties and walk up the sysfs device tree to find valid match keys for custom rules.

# Query device properties by device node
$ udevadm info --query=all --name=/dev/sda1
P: /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1
N: sda1
S: disk/by-id/ata-Samsung_SSD_870_EVO_500GB_S5YBNF0R123456-part1
S: disk/by-uuid/a3c4d5e6-1234-4567-89ab-cdef01234567
E: DEVNAME=/dev/sda1
E: DEVTYPE=partition
E: ID_BUS=ata
E: ID_FS_TYPE=ext4
E: ID_FS_UUID=a3c4d5e6-1234-4567-89ab-cdef01234567

The Critical --attribute-walk Flag

$ udevadm info -a -p /sys/class/net/eth0
# or
$ udevadm info --attribute-walk --name=/dev/sdb

This command prints all sysfs attributes for the specified device and every parent device in its chain. When writing rules:

• You can mix ATTR{} attributes from the device itself.
• You can match ATTRS{} from one single parent device, but you cannot combine ATTRS{} from multiple different parent devices in the same rule.

2. udevadm monitor (Live Event Monitoring)

udevadm monitor listens to kernel netlink uevents and udev processed events in real time. It is invaluable for troubleshooting what happens when hardware is attached or removed.

$ sudo udevadm monitor --property
KERNEL[1532.102319] add      /devices/pci0000:00/0000:00:14.0/usb1/1-3 (usb)
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-3
SUBSYSTEM=usb
DEVNAME=/dev/bus/usb/001/004
DEVTYPE=usb_device
PRODUCT=781/5581/100

UDEV  [1532.145892] add      /devices/pci0000:00/0000:00:14.0/usb1/1-3 (usb)
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-3
SUBSYSTEM=usb
DEVNAME=/dev/bus/usb/001/004
DEVTYPE=usb_device

• --kernel: Prints only raw kernel uevents.
• --udev: Prints only events after udev rule processing.
• --property: Prints the complete environment payload of each event.

3. udevadm test and udevadm control

• udevadm test <sysfs_path>: Simulates udev rule processing for a device path (e.g., udevadm test /sys/class/net/eth0). It prints all rules traversed, showing what symlinks, permissions, and RUN commands would be applied without actually executing RUN programs.
• udevadm control --reload-rules (or udevadm control --reload): Forces systemd-udevd to re-read all rules files from disk after you create or edit a file in /etc/udev/rules.d/.
• udevadm trigger: Synthesizes kernel uevents for all currently existing devices (coldplug), forcing udev to re-evaluate rules and apply new symlinks/permissions immediately without physically unplugging and replugging the hardware.

5. Inter-Process Communication & The D-Bus System

D-Bus (Desktop Bus) is a standard message bus system that provides inter-process communication (IPC) and remote procedure calls (RPC). It allows system daemons, hardware subsystems, and user applications to communicate seamlessly without custom sockets or pipes.

D-Bus Architecture: Two Bus Instances

Key D-Bus Daemons & Utilities

• dbus-daemon: The central message broker daemon managing bus routing and security policies.
• dbus-send: Sends a message to a D-Bus interface from the shell.
• dbus-monitor: Monitors and prints messages traveling across the system or session bus.
• gdbus / qdbus: Tooling for inspecting objects, methods, and signals on D-Bus.

6. Enabling and Disabling Integrated Peripherals

Objective 101.1 opens with "enable and disable integrated peripherals," and exam items on it turn on which layer the peripheral was switched off at. A typical board integrates a network controller, an audio codec, serial and parallel ports, SATA/NVMe controllers, USB host controllers, and CPU virtualization extensions. Each can be disabled in firmware, in the kernel's module configuration, or at runtime through sysfs — and the three choices produce visibly different diagnostic output.

Layer 1: Firmware Setup (BIOS/UEFI)

Firmware setup is entered during POST (commonly Del, F2, F10, or Esc) and exposes menus named Integrated Peripherals, Onboard Devices, or Advanced → Chipset. Common toggles include Onboard LAN, HD Audio, serial/parallel ports together with their I/O port and IRQ assignments, SATA controller mode (AHCI, RAID, or legacy IDE), USB controllers and legacy USB support, Intel VT-x / AMD-V, and Secure Boot.

A peripheral disabled here is never presented on the bus, so the kernel cannot see it at all:

• it is absent from lspci and lsusb entirely;
• no matching directory exists under /sys/bus/pci/devices/;
• no uevent fires, so udev never auto-loads a driver for it;
• it claims no resources in /proc/interrupts or /proc/ioports.

Layer 2: Kernel Module Configuration

Leaving the device enabled in firmware but refusing to drive it is a software decision, handled through /etc/modprobe.d/*.conf (blacklist, and install <module> /bin/false for a hard block) or the modprobe.blacklist= kernel command-line parameter — covered in detail in section 2.1. The device stays fully visible to lspci; only the Kernel driver in use: line disappears.

Layer 3: Runtime sysfs Unbinding and USB Authorization

sysfs exposes per-driver and per-device controls that take effect immediately, with no reboot and no configuration file:

# Detach the driver from one PCI function (the device itself stays visible)
$ echo 0000:00:1f.6 | sudo tee /sys/bus/pci/drivers/e1000e/unbind

# Reattach the same function to its driver later
$ echo 0000:00:1f.6 | sudo tee /sys/bus/pci/drivers/e1000e/bind

# Remove the device from the kernel's view completely, then rescan the bus
$ echo 1 | sudo tee /sys/bus/pci/devices/0000:00:1f.6/remove
$ echo 1 | sudo tee /sys/bus/pci/rescan

# Deauthorize a single USB device without physically unplugging it
$ echo 0 | sudo tee /sys/bus/usb/devices/1-3/authorized

# Refuse new devices plugged into a given root hub by default
$ echo 0 | sudo tee /sys/bus/usb/devices/usb1/authorized_default

Every sysfs change above is volatile — the device returns on the next boot unless the state is persisted through a udev rule or a modprobe.d entry.

Choosing the Right Layer

Exam Trap — Where Did the NIC Go? If lspci lists no Ethernet controller at all, the device is disabled in firmware or physically absent; no amount of driver work will recover it. If lspci -k shows the controller but prints no Kernel driver in use: line, the hardware is enabled and the problem is a blacklisted, missing, or unbound driver.