Linux··5 min

The /sys Filesystem and udev

/sys exposes the kernel's hardware device tree as a filesystem. Every device, driver binding, and hardware parameter is visible and writable. udev sits on top and automates responses to hardware events. Together they are the kernel's live hardware interface.

/sys is the other major virtual filesystem alongside /proc. Where /proc exposes process and kernel state, /sys exposes the hardware device tree — every device the kernel knows about, organised by how it connects to the system. It is also the primary interface for configuring hardware behaviour at runtime.

sysfs vs procfs

/proc grew organically over decades and became a mix of process info and general kernel state. /sys was introduced in Linux 2.6 to provide a cleaner, structured representation of the kernel's device model.

The key difference:

  • /proc is mostly read-only kernel state and per-process info
  • /sys is the live device tree with writable files for controlling hardware

The /sys structure

ls /sys
block  bus  class  dev  devices  firmware  fs  hypervisor  kernel  module  power

The most important directories:

DirectoryContents
/sys/devices/The full device tree, mirroring the physical hardware topology
/sys/bus/Devices organised by bus type (pci, usb, platform, i2c, etc.)
/sys/class/Devices organised by class (net, block, input, etc.)
/sys/block/Block devices (disks)
/sys/module/Loaded kernel modules and their parameters
/sys/kernel/Kernel internals
/sys/power/Power management

Exploring hardware

Network interfaces

ls /sys/class/net/

Each interface has a directory. Inside:

cat /sys/class/net/eth0/address        # MAC address
cat /sys/class/net/eth0/speed          # link speed in Mbps
cat /sys/class/net/eth0/operstate      # up/down/unknown
cat /sys/class/net/eth0/statistics/rx_bytes   # received bytes
cat /sys/class/net/eth0/statistics/tx_bytes   # transmitted bytes

Block devices

ls /sys/block/
cat /sys/block/sda/size              # size in 512-byte sectors
cat /sys/block/sda/queue/rotational  # 1 = HDD, 0 = SSD
cat /sys/block/sda/queue/scheduler   # I/O scheduler

Check if a disk is an SSD:

cat /sys/block/sda/queue/rotational

0 means SSD. 1 means spinning disk.

PCI devices

ls /sys/bus/pci/devices/

Each device is identified by its PCI address (domain:bus:device.function). Follow symlinks to the device tree:

cat /sys/bus/pci/devices/0000:02:00.0/vendor   # vendor ID (hex)
cat /sys/bus/pci/devices/0000:02:00.0/device   # device ID (hex)
cat /sys/bus/pci/devices/0000:02:00.0/driver   # symlink to driver

CPU topology

ls /sys/devices/system/cpu/
cat /sys/devices/system/cpu/cpu0/topology/physical_package_id   # which socket
cat /sys/devices/system/cpu/cpu0/topology/core_id               # which core
cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list  # sibling HT threads

CPU frequency scaling:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor       # current governor
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq       # current frequency
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

Change the CPU frequency governor:

echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Governors:

  • performance — always run at maximum frequency
  • powersave — always run at minimum frequency
  • ondemand — scale up under load, scale down when idle
  • schedutil — modern scheduler-based scaling (default on most kernels)

Controlling hardware via /sys

Brightness (laptops)

cat /sys/class/backlight/intel_backlight/max_brightness
echo 500 | sudo tee /sys/class/backlight/intel_backlight/brightness

LED control

ls /sys/class/leds/
echo 0 | sudo tee /sys/class/leds/input2::capslock/brightness   # turn off caps lock LED

Power management

cat /sys/power/state    # available sleep states: freeze mem disk
echo mem | sudo tee /sys/power/state   # suspend to RAM

Disk power management:

cat /sys/block/sda/device/power/control   # auto or on
echo on | sudo tee /sys/block/sda/device/power/control   # disable power management

Driver binding and unbinding

You can detach a device from its driver and attach it to a different one without rebooting.

Unbind a device from its current driver:

echo "0000:02:00.0" | sudo tee /sys/bus/pci/devices/0000:02:00.0/driver/unbind

Bind it to a new driver:

echo "0000:02:00.0" | sudo tee /sys/bus/pci/drivers/vfio-pci/bind

This is how GPU passthrough to virtual machines works — the GPU is unbound from the host driver and bound to vfio-pci.

udev

udev is the device manager for the Linux kernel. It runs in userspace and responds to kernel events (uevents) when hardware is added or removed.

When you plug in a USB device, the kernel detects it and sends a uevent. udev receives that event and applies rules to decide what to do — create a /dev entry, set permissions, load a module, run a script.

udev rules

Rules live in /etc/udev/rules.d/ (user rules) and /lib/udev/rules.d/ (system rules). Files are processed in alphanumeric order — lower numbers run first.

A rule file is named NN-description.rules where NN is a number.

Rule syntax uses comma-separated key-value pairs. Match keys identify the device. Assignment keys take action.

# Match a USB device by vendor and product ID, rename the symlink
SUBSYSTEM=="usb", ATTRS{idVendor}=="1234", ATTRS{idProduct}=="5678", SYMLINK+="mydevice"

# Match a block device and set permissions
SUBSYSTEM=="block", KERNEL=="sdb", OWNER="jan", GROUP="disk", MODE="0660"

# Run a script when a specific USB is plugged in
SUBSYSTEM=="usb", ATTRS{idVendor}=="1234", ACTION=="add", RUN+="/home/jan/scripts/usb-plugged.sh"

Match operators:

  • == — match
  • != — not match

Assignment operators:

  • = — assign
  • += — append
  • := — assign and lock (no further rules can change this)

Finding device attributes for rules

To write a rule for a specific device, you need its attributes. Plug in the device and run:

udevadm info --query=all --name=/dev/sdb

Or using the sysfs path:

udevadm info --attribute-walk --path=/sys/bus/usb/devices/1-1

Walk up the device tree to find attributes at any level.

Testing and reloading rules

Test what rules would match a device without triggering them:

udevadm test /sys/bus/usb/devices/1-1

Reload rules after editing:

sudo udevadm control --reload-rules
sudo udevadm trigger

udevadm monitor

Watch uevents in real time — useful when diagnosing device detection issues:

sudo udevadm monitor

Plug in a device and watch what events the kernel sends and how udev responds.


/sys and udev together form the kernel's live interface to hardware. /sys lets you read and control hardware state directly. udev automates the response to hardware events. Between them you have everything you need to understand, control, and automate hardware behaviour on Linux.

Next up: kernel parameters and sysctl — tuning the running kernel for performance and security.

0 views