udev

The Linux kernel reports device changes to user space through uevents. On many current distributions, systemd-udevd processes those events using udev rules and a device database. Together with kernel-populated devtmpfs, this produces the ownership, permissions, properties, and symbolic links applications see around /dev.

From Kernel Event to Device Policy

When a device is added, changed, moved, or removed, udev can:

• read attributes from sysfs and event properties
• apply owner, group, and mode policy to a device node
• add stable symbolic links such as /dev/disk/by-id/...
• tag devices for other services
• run narrowly defined helper processing

The kernel remains responsible for the actual device and its driver. Deleting a node from /dev does not physically remove hardware, and manually creating a node with mknod does not make unsupported hardware exist or bind a driver.

Rule Locations and Precedence

Rules commonly reside in:

• /usr/lib/udev/rules.d/ for vendor or package-provided rules
• /run/udev/rules.d/ for volatile runtime rules
• /etc/udev/rules.d/ for local administrator policy

Files are processed in lexical filename order, with same-named files in higher-priority directories replacing lower-priority versions according to the installed udev implementation. Local rules should use a deliberate filename and match stable properties rather than enumeration names.

A rule can affect every matching device, so test scope carefully. Do not edit packaged rules directly when a local override or supplementary rule is appropriate.

Inspecting a Device with udevadm

Query udev properties for an existing node:

$ udevadm info --query=all --name=/dev/sda

Use a node that exists on the current system. udevadm info --attribute-walk --name=... can display attributes along the sysfs parent chain, which helps construct a rule. udevadm monitor --kernel --udev --property observes kernel and processed events; it may expose device identifiers, so handle captured output appropriately.

Applying Rule Changes Carefully

Reloading rule files affects future event processing; it does not automatically reconstruct every existing device state. Triggering events manually can affect many devices and services, so narrow the target and use the installed udevadm documentation. A testing command can simulate rule evaluation but may not reproduce every real event side effect.

Back up local rules, validate syntax, observe one known test device, and keep a recovery path before changing permissions or names. Avoid long-running work directly in udev event processing; delegate it to an appropriate service.

Use Explore Hardware Devices in Linux to correlate udevadm properties, sysfs paths, and /dev links in a controlled environment.

Summary

You can now place udev between kernel events and user-space device policy.

1. Relate uevents and sysfs attributes to udev rule matching.
2. Separate vendor, runtime, and local rule locations.
3. Inspect properties and event flow with udevadm.
4. Reload and trigger rules only with a narrow, tested scope.