Udev

Let’s take this slowly and in great detail, so you understand not just what /etc/udev/rules.d is, but also why it exists, how it works, and how you can use it.

🧠 Part 1: Understanding the “udev” system

🔹 What is “udev”?

udev stands for userspace /dev manager. It is a device manager for the Linux kernel — it runs in userspace (not in kernel space) and dynamically manages device nodes under the /dev directory.

🔹 Purpose of udev

Whenever you connect a hardware device to your Linux system (for example, a USB flash drive, camera, Bluetooth dongle, or even an emulator’s virtual device):

  • The kernel detects the hardware event (called a hotplug event).

  • The kernel then notifies udev.

  • udev decides:

    • What device file to create under /dev (e.g., /dev/ttyUSB0, /dev/sda1)

    • What permissions and ownership that device node should have

    • What symbolic links to create

    • Whether to run any scripts or custom actions (like mounting a disk or starting a service)

So, udev is like the “traffic controller” for all devices that get connected to your system.

⚙️ Part 2: Role of /etc/udev/rules.d

🔹 What is /etc/udev/rules.d?

This directory stores custom udev rules that tell the system how to handle specific devices when they are connected or detected.

Think of these as automation scripts for hardware events.

🔹 How the udev rule files are organized

udev reads its configuration rules from multiple locations (in this order of priority):

Directory
Purpose

/usr/lib/udev/rules.d/

Default system rules installed by packages

/run/udev/rules.d/

Runtime rules (temporary, generated at boot or dynamically)

/etc/udev/rules.d/

Custom user-defined rules (highest priority, overrides system rules)

👉 You (the user or administrator) put your custom rules in /etc/udev/rules.d.

🔹 Naming convention

Rule files usually end with .rules. Example:

The number at the start (e.g., 99-) determines the load order. Lower numbers load earlier, higher numbers load later.

🧩 Part 3: What a udev rule looks like

Let’s see an example of a custom udev rule.

Example 1: Set permissions for a specific USB device

Suppose you connect a USB device (say, a microcontroller board) that always shows up as /dev/ttyUSB0, but you want:

  • to give it a friendly name /dev/myboard, and

  • make it readable/writable by your user without sudo.

You can create this rule file:

Add this line:

Explanation:

  • SUBSYSTEM=="tty" → Applies to serial devices.

  • ATTRS{idVendor} and ATTRS{idProduct} → Match based on USB vendor/product IDs (you can get these from lsusb).

  • SYMLINK+="myboard" → Creates a symbolic link /dev/myboard.

  • MODE="0666" → Sets permissions to read/write for all users.

Now when you plug in that device, /dev/myboard appears automatically!

🪄 Part 4: How udev rules work internally

1. Event detection

When a device is connected, the kernel generates an “add” event (or “remove” when disconnected).

2. udevd daemon

The udevd daemon listens to these kernel events through the netlink socket and loads matching rules.

3. Rule matching

udev goes through all the rule files in:

and applies all rules that match the device’s attributes.

4. Rule execution

For each matching rule, it can:

  • Create device nodes (/dev/sda, /dev/ttyUSB0, etc.)

  • Set permissions and ownership

  • Create symlinks

  • Run scripts (via RUN+=)

  • Change environment variables

🧰 Part 5: Common Use Cases

Use Case
Example

Assign stable names to devices

Give consistent names like /dev/mycamera even if /dev/video0 changes

Automatically mount USB drives

Run a script to mount a drive under /media/usb

Set permissions for USB devices

Make Arduino or Android devices accessible without sudo

Start services on device connection

Start a backup script when an external disk is attached

Ignore or disable certain devices

Prevent the system from creating a /dev entry for unwanted devices

🧾 Example 2: Automatically run a script when USB is inserted

File: /etc/udev/rules.d/90-usb-backup.rules

This means:

  • When a new block device (like a USB storage device) is added,

  • Run /usr/local/bin/backup.sh.

You can add logic in backup.sh to back up your files.

🔍 Part 6: Testing and Debugging udev rules

1. Reload rules after editing:

2. Trigger udev manually (without replugging):

3. Monitor udev events live:

This shows you which events are being triggered when you plug or unplug devices.

4. Check detailed device attributes:

This shows all attributes you can use to match your rule (idVendor, idProduct, serial, product, etc.)

🧠 Part 7: Summary (Key Takeaways)

Concept
Description

udev

Userspace device manager for Linux

Purpose

Dynamically manages device nodes in /dev

Rules location

/etc/udev/rules.d for user-defined rules

Other locations

/usr/lib/udev/rules.d (system), /run/udev/rules.d (runtime)

Rules syntax

Key-value pairs (e.g., ACTION==, SUBSYSTEM==, RUN+=)

Use cases

Rename devices, set permissions, auto-run scripts, assign symlinks

Test tools

udevadm info, udevadm control --reload-rules, udevadm monitor

⚡ Real-World Example (related to your domain)

In automotive or embedded Linux (like AOSP or Cuttlefish):

  • You might use udev rules to:

    • Automatically identify connected USB devices (e.g., OBD-II adapter or ADB device)

    • Assign stable names to CAN interfaces (like can0, can1)

    • Trigger startup scripts when automotive sensors (GPS, modem) are detected

    • Grant non-root access to developers or apps that need serial or USB permissions

Would you like me to show you a real example udev rule that’s commonly used in Android or AOSP environments (for example, to automatically set permissions for ADB devices like /dev/bus/usb/*)? That will help you see how /etc/udev/rules.d connects to your automotive AOSP work.

PreviousEnvironment Variables in Ubuntu LinuxNextSymlinks

Last updated