udev, hotplug, and hardware information
Devices come and go while the system runs. udev creates device files, names them consistently, and runs rules, while a toolkit of commands reveals what hardware is present.
devtmpfs and udev
The kernel creates basic device nodes automatically in /dev using devtmpfs. udev, part of systemd as systemd-udevd, listens for kernel events (uevents) as devices appear and disappear, then applies rules that set permissions and ownership, create convenient symbolic links, load firmware or modules, and notify other programs such as desktop environments.
Persistent names
Kernel names such as /dev/sdb depend on detection order and can change. udev creates stable symbolic links: /dev/disk/by-uuid/, /dev/disk/by-id/ (based on model and serial number), /dev/disk/by-label/, and /dev/disk/by-path/ (based on physical connection). Network interfaces get predictable names such as enp3s0 (PCI bus 3, slot 0) or wlp2s0 for Wi-Fi, instead of eth0 and wlan0, which could swap between boots.
udev rules
Rules in /etc/udev/rules.d/ (overriding defaults in /usr/lib/udev/rules.d/) match device attributes and take actions. For example, a rule matching a USB device's vendor and product IDs can set MODE="0660", GROUP="plugdev", and SYMLINK+="my-sensor", so the device always appears as /dev/my-sensor with suitable permissions. udevadm info shows a device's attributes for writing rules; udevadm control --reload applies changes.
Monitoring events
udevadm monitor prints kernel and udev events in real time, which helps debug hotplug problems: plugging in a USB stick shows add events for the USB device, its partitions, and their block devices. journalctl -f and dmesg -w follow the corresponding log messages.
Hardware inventory
Useful commands include lscpu (CPU architecture, cores, caches, and flags), lsblk (block devices), lspci and lsusb (PCI and USB devices), lshw and inxi (detailed summaries, if installed), dmidecode (firmware tables with motherboard, memory, and serial details, as root), and sensors from lm-sensors (temperatures and fan speeds). /proc/cpuinfo and /proc/meminfo provide raw details.
Power management
Linux manages power through CPU frequency scaling (cpufreq governors such as schedutil and performance), idle states, suspend to RAM (systemctl suspend), and hibernation to disk. Runtime power management turns off idle devices such as USB controllers or GPUs. Tools such as powertop show what is consuming power and suggest tunings, especially on laptops.
Graphics and input
Graphics drivers use the kernel's Direct Rendering Manager (DRM) and kernel mode setting (KMS), with user-space libraries such as Mesa providing OpenGL and Vulkan. Display servers use Wayland, now the default on major desktops, or the older X11. Input devices such as keyboards, mice, and touchpads appear as /dev/input/event* through the evdev interface, handled in user space by libinput.
Worked example
An embedded sensor appears as /dev/ttyACM0 or /dev/ttyACM1 depending on the order devices are plugged in, breaking a data-logging script. udevadm info -a -n /dev/ttyACM0 shows idVendor 2341 and idProduct 0043. A rule file /etc/udev/rules.d/99-sensor.rules containing SUBSYSTEM=="tty", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="0043", SYMLINK+="sensor", GROUP="dialout" makes /dev/sensor always point to the right device, and the script uses that path.
Key takeaways
devtmpfs creates basic device nodes; udev (systemd-udevd) handles uevents, setting permissions, creating symlinks, loading firmware, and notifying programs. Stable names live under /dev/disk/by-uuid, by-id, by-label, and by-path, and network interfaces get predictable names such as enp3s0. udev rules in /etc/udev/rules.d match attributes to set modes, groups, and symlinks; udevadm info, monitor, and control help. lscpu, lsblk, lspci, lsusb, lshw, dmidecode, and sensors inventory hardware. cpufreq governors, suspend, hibernation, runtime power management, and powertop manage power. Graphics use DRM, KMS, and Mesa with Wayland or X11; input uses evdev and libinput.
Flashcard
Kernel-maintained /dev file system
Check your understanding
Why are network interfaces given names like enp3s0 instead of eth0?