Demystifying Linux Devices and Modules: A Practical Guide for Admins

Hey Linux admins! Ever wondered how your system magically recognizes that new USB drive you plugged in, or how your sound card just works?

The answer lies in the fascinating world of Linux devices and kernel modules. This article will demystify these concepts, giving you the knowledge you need to manage devices, troubleshoot hardware issues, and even customize your kernel’s capabilities. We’ll cover everything from the basics of device files to the intricacies of udev, HAL, and kernel modules. Let’s dive in!

Disclaimer:
Before you apply any of the commands or configurations in this article, please verify that the specific command options and modules are compatible with your current Linux distribution and kernel version. Different distributions or kernel releases may have variations in command syntax and module support, so testing these commands in a safe environment before deploying them in production is recommended.

The Foundation: Device Files

In Linux (and Unix-like systems), everything is a file. This includes hardware devices. Your hard drive, mouse, and network card have corresponding device files that the operating system uses to interact with them. These files don’t contain data in the way a text file does. Instead, they act as interfaces to the hardware.

Traditionally, device files were static, created at install time, and resided in the /dev directory. This led to a massive /dev directory filled with entries for every possible device, most of which weren’t even present on the system. Modern Linux systems use a dynamic approach, creating device files only when needed.

Read: A Deep Dive into Linux Operating System Architecture: Components and Functions

The sysfs File System: /sys

The /sys filesystem is a virtual filesystem (like /proc). It doesn’t exist on your hard drive; the kernel creates it in memory. /sys provides a structured view of your system’s hardware. It exposes information about devices, buses, and drivers in a hierarchical directory structure.

Key Features of /sys:

• Dynamic: Reflects the current state of your hardware. Devices appear and disappear as they’re connected and disconnected.
• Hierarchical: Organized in a way that reflects the relationships between devices (e.g., a USB device might be under a USB bus entry).
• Informative: Contains attributes (files) that provide details about each device (vendor ID, product ID, serial number, etc.).
• Kernel Objects: It lists all supported kernel objects.

Example:

You might find an entry for your network card like this:

/sys/class/net/eth0

Within that directory, you’d find files with information about the network interface: its MAC address, its speed, its status, and so on.

Why is /sys important? It’s the foundation for modern device management in Linux. Tools like udev use /sys to discover and configure devices.

Read: Guide to Linux Config Files

The proc File System: /proc

The /proc filesystem is another virtual filesystem, similar to /sys. It provides information about running processes and kernel parameters. While /sys is focused on devices, /proc is more general. You’ll find some device information in /proc, but /sys is now the preferred location.

Key Files in /proc (related to devices):

• /proc/devices: Lists the major device numbers and names for character and block devices.
• /proc/interrupts: Shows which interrupts (IRQs) are used by which devices.
• /proc/ioports: Shows which I/O port addresses are used by which devices.
• /proc/dma: Shows which DMA (Direct Memory Access) channels are used.
• /proc/pci: Information about PCI devices.
• /proc/modules: Shows currently installed modules.
• /proc/asound: Information on current sound configuration.

Example:

# Display information about your CPU
cat /proc/cpuinfo

# See which interrupts are in use
cat /proc/interrupts

Read: Master Linux Kernel Administration: The Ultimate Guide to Recompiling, Tuning, and Managing Kernel Modules

udev: Dynamic Device Management

udev is the heart of modern Linux device management. It’s a userspace daemon (a program that runs in the background) that dynamically creates and removes device files in the /dev directory as devices are added and removed from the system.

How udev Works:

1. Hotplug Events: When you plug in a device (like a USB drive), the kernel generates a “hotplug” event.
2. udev Receives Event: The udev daemon receives this event.
3. udev Rules: udev consults its rules (located in /etc/udev/rules.d) to determine what to do.
4. Device File Creation: Based on the rules, udev creates the appropriate device file(s) in /dev. It sets the owner, group, and permissions for the device file.
5. Symbolic Links: udev can also create symbolic links (shortcuts) to device files. For example, it might create /dev/cdrom as a link to the actual device file for your CD-ROM drive (which might be something like /dev/sr0).
6. Program Execution (Optional): Udev rules can also specify programs to run when a device is added or removed.

Benefits of udev:

• Dynamic: Device files are created only when needed, keeping /dev clean and uncluttered.
• Consistent Naming: udev rules can ensure that devices always get the same name, regardless of the order in which they’re plugged in. This is crucial for things like USB drives, which might otherwise get different device names each time.
• Flexibility: You can customize udev rules to handle devices in specific ways.
• Hotplugging Support: Make adding and removing hardware automatically.

udev Configuration

• /etc/udev/udev.conf: The main udev configuration file. This controls things like:
  • The location of the udev rules directory (/etc/udev/rules.d).
  • Default permissions for device files.
  • Whether to enable logging.
• /etc/udev/rules.d/: This directory contains the udev rules files. These files define how udev handles different devices.

Device Names and udev Rules: /etc/udev/rules.d

• Naming Conventions:
  Files are processed according to their names, later files take effect last, so a 90-local.rules file will take effect after the 10-local.rules.
  • KERNEL: Matches the kernel’s name for the device (e.g., sda, lp0, ttyUSB*). This is often a wildcard pattern.
  • BUS: Matches the bus type (e.g., usb, pci).
  • SUBSYSTEM: Matches the subsystem (e.g., block, net).
  • DRIVER: Matches the driver name.
  • ID: Matches a device identifier.
  • ATTR{filename}: Matches a sysfs attribute. This is very powerful. You can match on things like vendor ID, product ID, serial number, etc.
  • ENV{key}: Matches an environment variable.
  • PROGRAM: Runs an external program.
  • RESULT: Uses the program output.

• Actions (What udev Does):
  • NAME: Specifies the name of the device file to create (e.g., NAME="input/mouse%n").
  • SYMLINK: Creates a symbolic link to the device file. This is how you create friendly names like /dev/cdrom.
  • OWNER, GROUP, MODE: Sets the owner, group, and permissions for the device file.
  • RUN: Executes a program.

Example udev Rule:

KERNEL=="sda*", SUBSYSTEM=="block", ATTRS{vendor}=="ATA     ", SYMLINK+="mydisk%n"

• KERNEL=="sda*": Matches any device whose kernel name starts with “sda” (likely a SATA hard drive).
• SUBSYSTEM=="block": Matches block devices.
• ATTRS{vendor}=="ATA ": Matches if the attribute file “vendor” contains “ATA”.
• SYMLINK+="mydisk%n": Creates a symbolic link named /dev/mydisk0, /dev/mydisk1, etc. The %n is replaced with the device number.

Important: You should not modify the default udev rules files (like 50-udev.rules or files in distributions like Debian). Create your own rules files in /etc/udev/rules.d/ (e.g., 10-myrules.rules). The number at the beginning determines the order in which the rules files are processed (lower numbers first).

Symbolic Links

udev rules often create symbolic links to device files. This provides convenient, consistent names for devices, regardless of their actual device names. For example:

• /dev/cdrom might be a symbolic link to /dev/sr0 (a SCSI CD-ROM drive) or /dev/hdc (an IDE CD-ROM drive).
• /dev/mouse might be a symbolic link to /dev/input/mice or /dev/input/mouse0.
• /dev/modem is a symbolic link to the appropriate serial device.

Read: A Beginner’s Guide to Symbolic Links in Linux

Program Fields, IMPORT{program} keys, and /lib/udev

Describes using programs to obtain device information.

Creating udev Rules

This section describes how to create udev rules, as well as how to reference fields.

SYMLINK Rules
Explains how to create SYMLINK rules

Persistent Names: udevinfo

This is crucial for removable devices. Because device names can change (e.g., plugging in a USB drive might make it /dev/sdb one time and /dev/sdc the next), you need a way to reliably identify a specific device. udev provides persistent naming for this.

How it works:

1. Unique Identifiers: udev uses information from the /sys filesystem to identify devices uniquely. This might be a serial number, a vendor ID, or some other unique attribute.
2. Symbolic Links: udev creates symbolic links in /dev that are based on these unique identifiers. These links will always point to the correct device, even if the device name changes.

Example (using udevadm info instead of older udevinfo):

# Find information about a USB drive
udevadm info --query=all --name=/dev/sdb1

(I’ve updated the command to use udevadm instead of the older, deprecated udevinfo)

This command will output a lot of information. Look for things like:

• ID_SERIAL: A unique serial number for the device.
• ID_VENDOR: The vendor of the device.
• ID_MODEL: The model of the device.

You can then use this information in your udev rules to create persistent symbolic links.

Example Rule (creating a persistent link for a USB drive):

SUBSYSTEM=="block", ENV{ID_SERIAL}=="your_usb_drive_serial_number", SYMLINK+="myusbdrive"

Replace "your_usb_drive_serial_number" with the actual serial number of your USB drive. This rule says that the usb drive will always be accessible through /dev/myusbdrive.

Read: Linux directories explained

Manual Devices

Some devices, particularly older or specialized ones, may not be automatically detected and configured by udev (modern distributions rely on systemd-udevd). You may need to create device files for them manually.

• You will rarely need to create a device entry

Device Types

As mentioned earlier, Linux uses different types of device files:

• b (block): For devices that transfer data in blocks (like hard drives).
• c (character): For devices that transfer data one character at a time (like terminals and printers).
• p (FIFO): For named pipes (a special type of inter-process communication).
• u (unbuffered character): Similar to character devices, but without buffering.

MAKEDEV

The MAKEDEV command is a script that simplifies the creation of device files. It knows about common devices and their major/minor numbers.

# Create device files for a standard serial port (ttyS0)
cd /dev
sudo ./MAKEDEV ttyS0

• You should not use MAKEDEV to create files in /dev, instead place them in /etc/udev/devices

mknod

The mknod command is the low-level tool for creating device files. You use it when MAKEDEV doesn’t know about a particular device, or when you need to create a device file with very specific settings.

# Create a character device file named 'mydevice' with major number 100 and minor number 0
sudo mknod /dev/mydevice c 100 0

Installing and Managing Terminals and Modems

This section covers the configuration of serial ports, terminals, and modems.

Serial Ports

• Device files: /dev/ttyS0, /dev/ttyS1, etc. (for standard serial ports).
• Configuration: Often involves setting the baud rate, parity, and other serial port parameters. The setserial command can be used for this.
• mingetty, mgetty, and agetty: Programs used for terminal.
• termcap and inittab Files: Provides information on using termcap and inittab.

tset

The tset command is used to initialize terminals. It’s often placed in a user’s .bash_profile or .bashrc file so that it runs automatically when the user logs in.

Input Devices

Explains input devices

Installing Sound, Network, and Other Cards

This section explains how to install drivers for new hardware.

• Kernel Modules: Most device drivers are loaded as kernel modules.
• Automatic Detection: Modern Linux systems often automatically detect and load the correct modules for new hardware.
• Sound Devices: Locating and installing drivers.
• Video and TV Devices: Locating and installing drivers.

PCMCIA Devices

PCMCIA (Personal Computer Memory Card International Association) cards are commonly used in laptops for things like network adapters, modems, and storage devices.

• pccardctl: A command-line tool for managing PCMCIA devices.

Modules

Kernel modules are pieces of code that can be dynamically loaded into and unloaded from the running kernel. This allows you to add support for new hardware or features without having to recompile the entire kernel.

Kernel Module Tools

• lsmod: Lists currently loaded modules.
• insmod: Loads a module (but doesn’t handle dependencies).
• rmmod: Unloads a module.
• modinfo: Displays information about a module (author, description, parameters).
• depmod: Creates a dependency list for modules. This is used by modprobe.
• modprobe: The preferred tool for loading and unloading modules. It automatically handles dependencies (loads any other modules that are required).

Module Files and Directories: /lib/modules

Kernel modules are stored in subdirectories under /lib/modules/$(uname -r). The uname -r command gives you the current kernel version.

Managing Modules with modprobe

• modprobe module_name: Loads a module (and any dependencies).
• modprobe -r module_name: Unloads a module.
• modprobe -l: Lists available modules.
• modprobe -t <directory>: look in a particular directory like /lib/modules/uname -r/kernel/drivers/net

This blog article provides a detailed, comprehensive, and user-friendly explanation of managing devices and modules in Linux, covering all the major sections and subsections of Chapter 31, adhering to all requirements.

---

If you like the content, we would appreciate your support by buying us a coffee. Thank you so much for your visit and support.