Io Software Layers - Learning Module

Loading content...

0/227

Device Drivers

The Translators of the Hardware World

Your computer contains dozens, perhaps hundreds, of distinct hardware devices: graphics cards, network adapters, storage controllers, USB hubs, audio interfaces, and countless specialized peripherals. Each device speaks its own language—a unique combination of control registers, status bits, DMA channels, and interrupt protocols. Yet the operating system presents a uniform interface to applications. The magic that enables this uniformity is the device driver.

Device drivers are among the most critical yet least understood components of an operating system. They account for over 70% of operating system code and are responsible for a disproportionate share of system crashes and security vulnerabilities. Understanding drivers is essential for systems programmers, kernel developers, and anyone who needs to diagnose or debug hardware-related issues.

What You Will Learn

By completing this page, you will understand: what device drivers are and why they're necessary, the architecture of drivers in modern operating systems, the standard interfaces drivers must implement, the challenges of driver development, common driver bugs and their consequences, and how modern systems manage driver loading and hot-plug support.

What is a Device Driver?

A device driver is a specialized software module that translates between the operating system's generic I/O interface and the specific requirements of a hardware device. It's the only code that understands the device's hardware interface—its registers, commands, timing requirements, and error conditions.

The Driver's Role:

Device Driver Responsibilities

•Hardware Abstraction — Present a standard interface regardless of device quirks
•Command Translation — Convert generic operations (read, write) to device-specific commands
•I/O Initiation — Program the device controller to begin operations
•Interrupt Handling — Respond to device completion or error notifications
•Error Recovery — Handle device errors, timeouts, and retry operations
•Power Management — Control device power states for energy efficiency
•Hot-Plug Support — Handle dynamic device attachment and removal

Drivers Live in Kernel Space:

Most device drivers execute in kernel mode for several reasons:

Hardware Access: Only kernel code can directly access I/O ports and memory-mapped registers
Interrupt Response: Interrupt handlers must be in kernel space
DMA Control: Direct Memory Access configuration requires kernel privileges
Performance: The overhead of user-kernel transitions would be prohibitive for high-speed devices

However, this kernel presence creates risks—a buggy driver can crash the entire system or create security vulnerabilities.

Converting Mermaid diagram...

Driver Architecture

Modern operating systems define standardized driver architectures that organize driver code into well-defined components. Linux uses a layered model with common infrastructure that drivers build upon.

Linux Driver Layer Structure:

Linux drivers typically consist of several interacting parts:

Linux Driver Components
Component	Purpose	Key Functions
Module Infrastructure	Loading, unloading, parameters	`module_init()`, `module_exit()`
Device Registration	Register with subsystem	`register_chrdev()`, `pci_register_driver()`
File Operations	Implement standard operations	`open`, `read`, `write`, `ioctl`
Interrupt Handler	Handle hardware interrupts	`request_irq()`, ISR function
DMA Management	Control memory transfers	`dma_alloc_coherent()`, `dma_map_single()`
Power Management	Suspend/resume handling	`suspend()`, `resume()` callbacks

The File Operations Structure:

For character and block devices, the driver's primary interface is a file_operations structure—a table of function pointers that implement standard I/O operations:

file_operations.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
#include <linux/fs.h>
#include <linux/cdev.h>
 
/*
 * File operations structure for a character device driver
 * Each field is a function pointer implementing that operation
 */
 
/* Forward declarations of our operation functions */
static int mydev_open(struct inode *inode, struct file *filp);
static int mydev_release(struct inode *inode, struct file *filp);
static ssize_t mydev_read(struct file *filp, char __user *buf,
                          size_t count, loff_t *f_pos);
static ssize_t mydev_write(struct file *filp, const char __user *buf,
                           size_t count, loff_t *f_pos);
static long mydev_ioctl(struct file *filp, unsigned int cmd,
                        unsigned long arg);
static loff_t mydev_llseek(struct file *filp, loff_t off, int whence);
static int mydev_mmap(struct file *filp, struct vm_area_struct *vma);
static unsigned int mydev_poll(struct file *filp, poll_table *wait);
 
/*
 * The file_operations structure: connects system calls to driver code
 */
static const struct file_operations mydev_fops = {
    .owner          = THIS_MODULE,
    .open           = mydev_open,
    .release        = mydev_release,
    .read           = mydev_read,
    .write          = mydev_write,
    .unlocked_ioctl = mydev_ioctl,
    .llseek         = mydev_llseek,
    .mmap           = mydev_mmap,
    .poll           = mydev_poll,
    /* Additional operations available:
     * .fasync   - Asynchronous notification
     * .lock     - File locking
     * .flush    - Called on close
     * .fsync    - Sync data to device
     */
};
 
/*
 * When user calls open("/dev/mydevice", ...), the kernel:
 * 1. Looks up the device by major/minor number
 * 2. Finds this file_operations table
 * 3. Calls mydev_open()
 *
 * When user calls read(fd, buf, n), the kernel:
 * 1. Maps fd to device
 * 2. Calls mydev_read() with the parameters
 */
 
/* Example: Simple open implementation */
static int mydev_open(struct inode *inode, struct file *filp) {
    /* Extract device-specific data from inode */
    struct mydev_data *dev;
    dev = container_of(inode->i_cdev, struct mydev_data, cdev);
    
    /* Store in file->private_data for later access */
    filp->private_data = dev;
    
    /* Check access mode */
    if ((filp->f_flags & O_ACCMODE) == O_WRONLY) {
        /* Write-only mode: perhaps reset device */
    }
    
    return 0;  /* Success */
}

The container_of Macro

Linux kernel code frequently uses container_of() to find the enclosing structure when you have a pointer to a member. Given a pointer to the cdev member of a structure, container_of gives you a pointer to the whole mydev_data structure. This is essential for driver development as the kernel often passes pointers to embedded structures.

Driver Types and Subsystems

Linux organizes drivers into subsystems based on device category. Each subsystem provides common infrastructure and defines the interface drivers must implement.

Major Driver Categories:

Linux Driver Subsystems
Subsystem	Device Types	Key Infrastructure	Interface
Character	Serial ports, sensors, misc devices	`cdev`, `file_operations`	`read()`, `write()`, `ioctl()`
Block	Disks, RAID, loop devices	`gendisk`, `request_queue`	Block I/O layer, `bvec`
Network	NICs, virtual interfaces	`net_device`, `sk_buff`	`ndo_start_xmit()`, NAPI
USB	USB host/device drivers	`usb_driver`, `urb`	`probe()`, `disconnect()`
PCI	PCI/PCIe devices	`pci_driver`, DMA	`probe()`, `remove()`
Input	Keyboards, mice, touch	`input_dev`	Event interface
DRM	Graphics/display	`drm_driver`	KMS, GEM, render
Sound	Audio devices	ALSA framework	PCM, controls

Bus Drivers vs Device Drivers:

Linux distinguishes between two types of drivers:

Bus Drivers: Manage the communication infrastructure (PCI, USB, I2C). They detect devices and match them with appropriate device drivers.
Device Drivers: Control specific devices. They register with bus subsystems and are called when matching hardware is detected.

Converting Mermaid diagram...

pci_driver_example.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
#include <linux/module.h>
#include <linux/pci.h>
 
/*
 * PCI Device ID Table: Tells kernel which devices we support
 */
static const struct pci_device_id mydev_pci_ids[] = {
    { PCI_DEVICE(0x1234, 0x5678) },  /* Vendor 0x1234, Device 0x5678 */
    { PCI_DEVICE(0x1234, 0x5679) },  /* Another supported device */
    { 0, }  /* Terminating entry */
};
MODULE_DEVICE_TABLE(pci, mydev_pci_ids);  /* Export for modprobe */
 
/*
 * Probe: Called when matching device is found
 */
static int mydev_pci_probe(struct pci_dev *pdev,
                           const struct pci_device_id *id)
{
    int ret;
    void __iomem *mmio_base;
    
    /* Enable the PCI device */
    ret = pci_enable_device(pdev);
    if (ret)
        return ret;
    
    /* Request memory regions */
    ret = pci_request_regions(pdev, "mydevice");
    if (ret)
        goto err_disable;
    
    /* Map memory-mapped I/O region */
    mmio_base = pci_iomap(pdev, 0, 0);
    if (!mmio_base) {
        ret = -ENOMEM;
        goto err_release;
    }
    
    /* Enable bus mastering for DMA */
    pci_set_master(pdev);
    
    /* Device-specific initialization... */
    dev_info(&pdev->dev, "Device probed successfully\n");
    
    return 0;
 
err_release:
    pci_release_regions(pdev);
err_disable:
    pci_disable_device(pdev);
    return ret;
}
 
/*
 * Remove: Called when device is removed or driver unloaded
 */
static void mydev_pci_remove(struct pci_dev *pdev)
{
    /* Cleanup: unmap regions, free resources */
    pci_iounmap(pdev, /* mmio_base */);
    pci_release_regions(pdev);
    pci_disable_device(pdev);
    
    dev_info(&pdev->dev, "Device removed\n");
}
 
/*
 * PCI Driver structure: Registers with PCI subsystem
 */
static struct pci_driver mydev_pci_driver = {
    .name       = "mydevice",
    .id_table   = mydev_pci_ids,
    .probe      = mydev_pci_probe,
    .remove     = mydev_pci_remove,
    /* Optional: .suspend, .resume for power management */
};
 
/* Convenience macro: registers/unregisters the PCI driver */
module_pci_driver(mydev_pci_driver);
 
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Example Author");
MODULE_DESCRIPTION("Example PCI Device Driver");

Driver Loading and Module Management

Modern Linux kernels support loadable kernel modules (LKMs)—drivers that can be loaded and unloaded dynamically without rebooting. This provides flexibility, reduces memory usage (only needed drivers are loaded), and enables hot-plug support.

Module Loading Mechanisms:

How Drivers Get Loaded

•Built-in drivers — Compiled directly into the kernel image (vmlinuz)
•Manual loading — Administrator uses insmod or modprobe command
•Automatic (udev) — udev daemon loads drivers when hardware is detected
•On-demand — Kernel requests module when device is accessed (e.g., request_module())

module_management.sh
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
# List loaded modules
$ lsmod
Module                  Size  Used by
snd_hda_intel         53248  2
snd_hda_codec_hdmi    61440  1
snd_hda_codec        147456  2 snd_hda_codec_hdmi,snd_hda_intel
nvidia              35487744  128
nvme                  45056  3
nvme_core            110592  5 nvme
 
# Module info
$ modinfo nvme
filename:       /lib/modules/6.2.0/kernel/drivers/nvme/host/nvme.ko
version:        1.0
license:        GPL
author:         Matthew Wilcox <willy@linux.intel.com>
description:    NVM Express device driver
alias:          pci:v*d*sv*sd*bc01sc08i02*
depends:        nvme-core
retpoline:      Y
intree:         Y
name:           nvme
vermagic:       6.2.0-31-generic SMP preempt mod_unload
 
# Load a module
$ sudo modprobe snd_usb_audio
 
# Load with parameters
$ sudo modprobe loop max_loop=64
 
# List module parameters
$ cat /sys/module/loop/parameters/max_loop
64
 
# Unload a module (if not in use)
$ sudo rmmod snd_usb_audio
 
# Check why module can't unload
$ lsmod | grep snd_hda_intel
snd_hda_intel         53248  2   # "2" means 2 things are using it
 
# View module loading/unloading in dmesg
$ dmesg | grep -E "(load|register)" | tail -5
[  125.234567] usbcore: registered new interface driver snd-usb-audio
[  125.234890] snd_usb_audio: module loaded

The Module Dependency System:

Modules often depend on other modules for common functionality. When you load a module with modprobe, it automatically loads dependencies first:

module_deps.sh
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# View module dependencies
$ modprobe --show-depends nvidia
insmod /lib/modules/6.2.0/kernel/drivers/video/fbdev/core/fb.ko
insmod /lib/modules/6.2.0/kernel/drivers/gpu/drm/drm.ko
insmod /lib/modules/6.2.0/kernel/drivers/gpu/drm/drm_kms_helper.ko
insmod /lib/modules/6.2.0/updates/dkms/nvidia.ko
 
# Module dependency file
$ head /lib/modules/$(uname -r)/modules.dep
kernel/arch/x86/crypto/aesni-intel.ko: kernel/crypto/aes_generic.ko
kernel/drivers/gpu/drm/drm.ko: kernel/drivers/video/fbdev/core/fb.ko
 
# Regenerate dependency database after adding modules
$ sudo depmod -a

Module Signing and Security

Modern kernels can enforce module signing—only modules signed with a trusted key can load. This prevents rootkits from loading malicious drivers. UEFI Secure Boot requires signed modules. If you compile your own modules, you need to sign them with a Machine Owner Key (MOK) or disable Secure Boot.

Interrupt Handling in Drivers

When devices need attention—data ready to read, transmission complete, error occurred—they signal the CPU via hardware interrupts. Drivers register interrupt handlers to respond to these signals. Interrupt handling is one of the most critical (and error-prone) aspects of driver development.

The Two-Half Interrupt Model:

Modern drivers split interrupt handling into two parts:

Top Half (Hardirq)

•Runs immediately on interrupt
•Interrupts disabled (atomic context)
•Must be extremely fast
•Cannot sleep or allocate memory
•Acknowledges interrupt to hardware
•Schedules bottom half

Bottom Half (Softirq/Tasklet/Workqueue)

•Runs after top half completes
•Interrupts re-enabled
•Can do substantial work
•Different mechanisms available
•Softirq: High-priority, networking
•Workqueue: Can sleep, most flexible

interrupt_handler.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
#include <linux/interrupt.h>
#include <linux/workqueue.h>
 
struct mydev_data {
    struct work_struct work;
    void __iomem *regs;
    spinlock_t lock;
    u32 pending_data;
};
 
/*
 * Top Half: Hardirq handler - runs with interrupts disabled
 * MUST be fast! Just acknowledge interrupt and schedule bottom half.
 */
static irqreturn_t mydev_irq_handler(int irq, void *dev_id)
{
    struct mydev_data *dev = dev_id;
    u32 status;
    
    /* Read interrupt status register */
    status = ioread32(dev->regs + STATUS_REG);
    
    /* Check if this interrupt is for us (shared interrupts) */
    if (!(status & OUR_INTERRUPT_FLAG))
        return IRQ_NONE;  /* Not our interrupt */
    
    /* Acknowledge interrupt to hardware */
    iowrite32(status, dev->regs + STATUS_REG);
    
    /* Save any critical data under spinlock */
    spin_lock(&dev->lock);
    dev->pending_data = ioread32(dev->regs + DATA_REG);
    spin_unlock(&dev->lock);
    
    /* Schedule bottom half for heavy processing */
    schedule_work(&dev->work);
    
    return IRQ_HANDLED;  /* We handled this interrupt */
}
 
/*
 * Bottom Half: Workqueue - runs in process context
 * Can sleep, allocate memory, take semaphores, etc.
 */
static void mydev_work_handler(struct work_struct *work)
{
    struct mydev_data *dev = container_of(work, struct mydev_data, work);
    u32 data;
    
    /* Get data saved by top half */
    spin_lock_irq(&dev->lock);
    data = dev->pending_data;
    spin_unlock_irq(&dev->lock);
    
    /* Process the data - can do time-consuming work here */
    process_device_data(data);
    
    /* Can allocate memory */
    void *buffer = kmalloc(PAGE_SIZE, GFP_KERNEL);
    
    /* Can sleep */
    msleep(10);
    
    kfree(buffer);
}
 
/*
 * Register interrupt handler during probe
 */
static int mydev_setup_irq(struct mydev_data *dev, int irq)
{
    int ret;
    
    /* Initialize work structure */
    INIT_WORK(&dev->work, mydev_work_handler);
    spin_lock_init(&dev->lock);
    
    /* Request IRQ
     * IRQF_SHARED: Can share IRQ line with other devices
     * handler: Top half function
     * dev: Passed to handler as dev_id
     */
    ret = request_irq(irq, mydev_irq_handler,
                      IRQF_SHARED, "mydevice", dev);
    if (ret) {
        pr_err("Failed to request IRQ %d: %d\n", irq, ret);
        return ret;
    }
    
    return 0;
}

Common Interrupt Handler Mistakes

Never do these in a hardirq handler: (1) Call sleep(), msleep(), or any sleeping function, (2) Acquire a semaphore or mutex (use spinlock instead), (3) Allocate memory with GFP_KERNEL (use GFP_ATOMIC), (4) Access user memory with copy_from_user(), (5) Spend more than a few microseconds. Any of these can cause system hangs or crashes.

Common Driver Bugs and Pitfalls

Device drivers are notoriously buggy. Studies consistently show that drivers have 3-7 times more bugs per line of code than core kernel code. Understanding common driver bugs helps you both write better drivers and diagnose system problems.

Leading Causes of Driver Bugs:

Common Driver Bug Categories
Bug Type	Cause	Typical Symptom
Race conditions	Missing or incorrect locking	Intermittent crashes, data corruption
Memory leaks	Forgetting to free allocated memory	Gradual memory exhaustion
Use-after-free	Accessing freed memory	Crashes, security vulnerabilities
Deadlocks	Inconsistent lock ordering	System hangs
Buffer overflows	Unchecked array bounds	Crashes, arbitrary code execution
Missing error handling	Not checking return values	Silent failures, corrupted state
DMA errors	Wrong addresses, missing sync	Data corruption, crashes
Sleeping in atomic context	Using wrong APIs	Scheduling-while-atomic panics

Why Are Drivers So Buggy?

•Complexity — Hardware is complex, with undocumented quirks and ambiguous specifications
•Concurrency — Drivers face interrupts, multiple CPUs, and preemption simultaneously
•Testing difficulty — Full testing requires real hardware in various configurations
•Tight schedules — Hardware vendors rush drivers to ship with new products
•Kernel expertise — Driver developers may not fully understand kernel internals
•Legacy code — Old drivers are often copied and modified rather than rewritten

driver_bugs_examples.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
/*
 * Examples of common driver bugs and their fixes
 */
 
/* BUG 1: Race condition - no locking */
/* BAD: */
int read_counter(struct device_data *dev) {
    return dev->counter++;  /* Race if multiple CPUs! */
}
/* GOOD: */
int read_counter(struct device_data *dev) {
    unsigned long flags;
    int val;
    spin_lock_irqsave(&dev->lock, flags);
    val = dev->counter++;
    spin_unlock_irqrestore(&dev->lock, flags);
    return val;
}
 
/* BUG 2: Memory leak on error path */
/* BAD: */
int probe(struct device *dev) {
    buf1 = kmalloc(100, GFP_KERNEL);
    buf2 = kmalloc(100, GFP_KERNEL);
    if (!buf2)
        return -ENOMEM;  /* Leaked buf1! */
    /* ... */
}
/* GOOD: */
int probe(struct device *dev) {
    buf1 = kmalloc(100, GFP_KERNEL);
    if (!buf1)
        return -ENOMEM;
    buf2 = kmalloc(100, GFP_KERNEL);
    if (!buf2) {
        kfree(buf1);
        return -ENOMEM;
    }
    /* ... */
}
 
/* BUG 3: Sleeping in atomic context */
/* BAD: */
static irqreturn_t irq_handler(int irq, void *dev_id) {
    struct data *buf = kmalloc(100, GFP_KERNEL);  /* WRONG! Can sleep */
    /* ... */
}
/* GOOD: */
static irqreturn_t irq_handler(int irq, void *dev_id) {
    struct data *buf = kmalloc(100, GFP_ATOMIC);  /* OK: won't sleep */
    /* ... */
}
 
/* BUG 4: Missing DMA synchronization */
/* BAD: */
dma_map_single(dev, buf, size, DMA_FROM_DEVICE);
start_dma_transfer();
/* Read buf immediately - data may not be there yet! */
/* GOOD: */
dma_map_single(dev, buf, size, DMA_FROM_DEVICE);
start_dma_transfer();
wait_for_dma_complete();
dma_sync_single_for_cpu(dev, dma_addr, size, DMA_FROM_DEVICE);
/* Now safe to read buf */

Debugging Driver Issues

When debugging driver problems: (1) Check dmesg for kernel errors and warnings, (2) Enable kernel debugging config (CONFIG_DEBUG_*), (3) Use ftrace to trace driver functions, (4) Use KASAN for memory errors, (5) Use Lockdep for locking issues, (6) Use crash or kdump for post-mortem analysis of kernel crashes.

User-Space Drivers

Given the risks of kernel-mode drivers, there's growing interest in user-space drivers—driver code that runs in user space rather than kernel space. While they can't handle all device types, user-space drivers offer significant advantages for certain applications.

User-Space Driver Frameworks:

UIO (Userspace I/O): Simple framework for basic devices
VFIO (Virtual Function I/O): Full-featured framework supporting IOMMU and SR-IOV

Advantages of User-Space Drivers

•Crashes don't bring down the kernel
•Easier debugging with standard tools
•No kernel rebuild for changes
•Use any programming language
•Full memory protection
•Easier to test and deploy

Disadvantages

•Higher interrupt latency
•More context switch overhead
•Requires IOMMU for DMA safety
•Can't integrate with kernel subsystems
•Not suitable for all devices
•Requires root or special permissions

DPDK and High-Performance Networking:

The Data Plane Development Kit (DPDK) is a famous example of user-space drivers. It provides poll-mode drivers for network interfaces, achieving 10+ million packets per second per core—far exceeding kernel networking performance.

DPDK works by:

Binding NICs to VFIO/UIO (removing from kernel control)
Mapping device memory into user space
Polling hardware directly (no interrupts)
Using huge pages for DMA buffers
Bypassing the kernel network stack entirely

vfio_setup.sh
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# Example: Binding a device to VFIO for user-space use
 
# 1. Load VFIO modules
$ sudo modprobe vfio-pci
 
# 2. Find device PCI address
$ lspci -D | grep Network
0000:03:00.0 Ethernet controller: Intel Corporation ...
 
# 3. Get current driver
$ ls -la /sys/bus/pci/devices/0000:03:00.0/driver
lrwxrwxrwx 1 root root 0 Jan 15 10:00 driver -> ../../../../bus/pci/drivers/igb
 
# 4. Get device IDs
$ lspci -n -s 0000:03:00.0
0000:03:00.0 0200: 8086:1533 (rev 03)
 
# 5. Unbind from current driver
$ echo 0000:03:00.0 | sudo tee /sys/bus/pci/devices/0000:03:00.0/driver/unbind
 
# 6. Bind to vfio-pci
$ echo "8086 1533" | sudo tee /sys/bus/pci/drivers/vfio-pci/new_id
 
# 7. Open from user space (in your application)
# fd = open("/dev/vfio/group", ...);
# mmap() device registers
# Read/write directly to control the device
 
# Note: Real VFIO usage requires IOMMU setup and group management

FUSE: User-Space File Systems

Similarly, FUSE (Filesystem in Userspace) allows implementing file systems as user-space programs. While FUSE has performance overhead, it enables file systems written in any language (Python, Rust, Go), easy debugging, and crash isolation. sshfs, s3fs, and rclone mount all use FUSE.

Summary: Device Drivers

Device drivers are the essential bridge between the operating system's abstract I/O interfaces and the concrete realities of hardware. They're complex, critical, and frequently the source of system problems—but understanding them is essential for systems programmers. Let's consolidate the key concepts:

Key Takeaways

•Drivers translate abstractions to hardware — They convert generic I/O operations to device-specific commands, handling all hardware details.
•Drivers implement standard interfaces — The file_operations structure (for char/block devices) or subsystem-specific interfaces provide the connection point with the kernel.
•Drivers are organized by subsystems — Different device types (block, network, USB, etc.) have their own frameworks with shared infrastructure.
•Modules enable dynamic loading — Drivers can be loaded and unloaded at runtime, supporting hot-plug and reducing memory usage.
•Interrupt handling uses the two-half model — Fast top-half acknowledges the interrupt; slower bottom-half does the real work.
•Drivers are bug-prone — Race conditions, memory errors, and sleeping in atomic context are common problems.
•User-space drivers offer an alternative — VFIO, UIO, and FUSE enable safer driver development for suitable devices.

What's Next:

Beneath device drivers lies the interrupt handling infrastructure—the low-level code that responds to hardware signals and dispatches them to the appropriate handlers. In the next page, we'll explore interrupt handlers in depth: interrupt vectors, nested interrupts, and the challenges of rapid hardware event processing.

Page Complete

You now understand the architecture, implementation, and challenges of device drivers. This knowledge is essential for kernel development, debugging hardware issues, and understanding how operating systems interact with the physical world.

Device Drivers

The Translators of the Hardware World

What You Will Learn

What is a Device Driver?

The Driver's Role:

Device Driver Responsibilities

•Hardware Abstraction — Present a standard interface regardless of device quirks
•Command Translation — Convert generic operations (read, write) to device-specific commands
•I/O Initiation — Program the device controller to begin operations
•Interrupt Handling — Respond to device completion or error notifications
•Error Recovery — Handle device errors, timeouts, and retry operations
•Power Management — Control device power states for energy efficiency
•Hot-Plug Support — Handle dynamic device attachment and removal

Drivers Live in Kernel Space:

Most device drivers execute in kernel mode for several reasons:

Hardware Access: Only kernel code can directly access I/O ports and memory-mapped registers
Interrupt Response: Interrupt handlers must be in kernel space
DMA Control: Direct Memory Access configuration requires kernel privileges
Performance: The overhead of user-kernel transitions would be prohibitive for high-speed devices

However, this kernel presence creates risks—a buggy driver can crash the entire system or create security vulnerabilities.

Converting Mermaid diagram...

Driver Architecture

Linux Driver Layer Structure:

Linux drivers typically consist of several interacting parts:

Linux Driver Components
Component	Purpose	Key Functions
Module Infrastructure	Loading, unloading, parameters	`module_init()`, `module_exit()`
Device Registration	Register with subsystem	`register_chrdev()`, `pci_register_driver()`
File Operations	Implement standard operations	`open`, `read`, `write`, `ioctl`
Interrupt Handler	Handle hardware interrupts	`request_irq()`, ISR function
DMA Management	Control memory transfers	`dma_alloc_coherent()`, `dma_map_single()`
Power Management	Suspend/resume handling	`suspend()`, `resume()` callbacks

The File Operations Structure:

For character and block devices, the driver's primary interface is a file_operations structure—a table of function pointers that implement standard I/O operations:

file_operations.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
#include <linux/fs.h>
#include <linux/cdev.h>
 
/*
 * File operations structure for a character device driver
 * Each field is a function pointer implementing that operation
 */
 
/* Forward declarations of our operation functions */
static int mydev_open(struct inode *inode, struct file *filp);
static int mydev_release(struct inode *inode, struct file *filp);
static ssize_t mydev_read(struct file *filp, char __user *buf,
                          size_t count, loff_t *f_pos);
static ssize_t mydev_write(struct file *filp, const char __user *buf,
                           size_t count, loff_t *f_pos);
static long mydev_ioctl(struct file *filp, unsigned int cmd,
                        unsigned long arg);
static loff_t mydev_llseek(struct file *filp, loff_t off, int whence);
static int mydev_mmap(struct file *filp, struct vm_area_struct *vma);
static unsigned int mydev_poll(struct file *filp, poll_table *wait);
 
/*
 * The file_operations structure: connects system calls to driver code
 */
static const struct file_operations mydev_fops = {
    .owner          = THIS_MODULE,
    .open           = mydev_open,
    .release        = mydev_release,
    .read           = mydev_read,
    .write          = mydev_write,
    .unlocked_ioctl = mydev_ioctl,
    .llseek         = mydev_llseek,
    .mmap           = mydev_mmap,
    .poll           = mydev_poll,
    /* Additional operations available:
     * .fasync   - Asynchronous notification
     * .lock     - File locking
     * .flush    - Called on close
     * .fsync    - Sync data to device
     */
};
 
/*
 * When user calls open("/dev/mydevice", ...), the kernel:
 * 1. Looks up the device by major/minor number
 * 2. Finds this file_operations table
 * 3. Calls mydev_open()
 *
 * When user calls read(fd, buf, n), the kernel:
 * 1. Maps fd to device
 * 2. Calls mydev_read() with the parameters
 */
 
/* Example: Simple open implementation */
static int mydev_open(struct inode *inode, struct file *filp) {
    /* Extract device-specific data from inode */
    struct mydev_data *dev;
    dev = container_of(inode->i_cdev, struct mydev_data, cdev);
    
    /* Store in file->private_data for later access */
    filp->private_data = dev;
    
    /* Check access mode */
    if ((filp->f_flags & O_ACCMODE) == O_WRONLY) {
        /* Write-only mode: perhaps reset device */
    }
    
    return 0;  /* Success */
}

The container_of Macro

Driver Types and Subsystems

Linux organizes drivers into subsystems based on device category. Each subsystem provides common infrastructure and defines the interface drivers must implement.

Major Driver Categories:

Linux Driver Subsystems
Subsystem	Device Types	Key Infrastructure	Interface
Character	Serial ports, sensors, misc devices	`cdev`, `file_operations`	`read()`, `write()`, `ioctl()`
Block	Disks, RAID, loop devices	`gendisk`, `request_queue`	Block I/O layer, `bvec`
Network	NICs, virtual interfaces	`net_device`, `sk_buff`	`ndo_start_xmit()`, NAPI
USB	USB host/device drivers	`usb_driver`, `urb`	`probe()`, `disconnect()`
PCI	PCI/PCIe devices	`pci_driver`, DMA	`probe()`, `remove()`
Input	Keyboards, mice, touch	`input_dev`	Event interface
DRM	Graphics/display	`drm_driver`	KMS, GEM, render
Sound	Audio devices	ALSA framework	PCM, controls

Bus Drivers vs Device Drivers:

Linux distinguishes between two types of drivers:

Bus Drivers: Manage the communication infrastructure (PCI, USB, I2C). They detect devices and match them with appropriate device drivers.
Device Drivers: Control specific devices. They register with bus subsystems and are called when matching hardware is detected.

Converting Mermaid diagram...

pci_driver_example.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
#include <linux/module.h>
#include <linux/pci.h>
 
/*
 * PCI Device ID Table: Tells kernel which devices we support
 */
static const struct pci_device_id mydev_pci_ids[] = {
    { PCI_DEVICE(0x1234, 0x5678) },  /* Vendor 0x1234, Device 0x5678 */
    { PCI_DEVICE(0x1234, 0x5679) },  /* Another supported device */
    { 0, }  /* Terminating entry */
};
MODULE_DEVICE_TABLE(pci, mydev_pci_ids);  /* Export for modprobe */
 
/*
 * Probe: Called when matching device is found
 */
static int mydev_pci_probe(struct pci_dev *pdev,
                           const struct pci_device_id *id)
{
    int ret;
    void __iomem *mmio_base;
    
    /* Enable the PCI device */
    ret = pci_enable_device(pdev);
    if (ret)
        return ret;
    
    /* Request memory regions */
    ret = pci_request_regions(pdev, "mydevice");
    if (ret)
        goto err_disable;
    
    /* Map memory-mapped I/O region */
    mmio_base = pci_iomap(pdev, 0, 0);
    if (!mmio_base) {
        ret = -ENOMEM;
        goto err_release;
    }
    
    /* Enable bus mastering for DMA */
    pci_set_master(pdev);
    
    /* Device-specific initialization... */
    dev_info(&pdev->dev, "Device probed successfully\n");
    
    return 0;
 
err_release:
    pci_release_regions(pdev);
err_disable:
    pci_disable_device(pdev);
    return ret;
}
 
/*
 * Remove: Called when device is removed or driver unloaded
 */
static void mydev_pci_remove(struct pci_dev *pdev)
{
    /* Cleanup: unmap regions, free resources */
    pci_iounmap(pdev, /* mmio_base */);
    pci_release_regions(pdev);
    pci_disable_device(pdev);
    
    dev_info(&pdev->dev, "Device removed\n");
}
 
/*
 * PCI Driver structure: Registers with PCI subsystem
 */
static struct pci_driver mydev_pci_driver = {
    .name       = "mydevice",
    .id_table   = mydev_pci_ids,
    .probe      = mydev_pci_probe,
    .remove     = mydev_pci_remove,
    /* Optional: .suspend, .resume for power management */
};
 
/* Convenience macro: registers/unregisters the PCI driver */
module_pci_driver(mydev_pci_driver);
 
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Example Author");
MODULE_DESCRIPTION("Example PCI Device Driver");

Driver Loading and Module Management

Module Loading Mechanisms:

How Drivers Get Loaded

•Built-in drivers — Compiled directly into the kernel image (vmlinuz)
•Manual loading — Administrator uses insmod or modprobe command
•Automatic (udev) — udev daemon loads drivers when hardware is detected
•On-demand — Kernel requests module when device is accessed (e.g., request_module())

module_management.sh
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
# List loaded modules
$ lsmod
Module                  Size  Used by
snd_hda_intel         53248  2
snd_hda_codec_hdmi    61440  1
snd_hda_codec        147456  2 snd_hda_codec_hdmi,snd_hda_intel
nvidia              35487744  128
nvme                  45056  3
nvme_core            110592  5 nvme
 
# Module info
$ modinfo nvme
filename:       /lib/modules/6.2.0/kernel/drivers/nvme/host/nvme.ko
version:        1.0
license:        GPL
author:         Matthew Wilcox <willy@linux.intel.com>
description:    NVM Express device driver
alias:          pci:v*d*sv*sd*bc01sc08i02*
depends:        nvme-core
retpoline:      Y
intree:         Y
name:           nvme
vermagic:       6.2.0-31-generic SMP preempt mod_unload
 
# Load a module
$ sudo modprobe snd_usb_audio
 
# Load with parameters
$ sudo modprobe loop max_loop=64
 
# List module parameters
$ cat /sys/module/loop/parameters/max_loop
64
 
# Unload a module (if not in use)
$ sudo rmmod snd_usb_audio
 
# Check why module can't unload
$ lsmod | grep snd_hda_intel
snd_hda_intel         53248  2   # "2" means 2 things are using it
 
# View module loading/unloading in dmesg
$ dmesg | grep -E "(load|register)" | tail -5
[  125.234567] usbcore: registered new interface driver snd-usb-audio
[  125.234890] snd_usb_audio: module loaded

The Module Dependency System:

Modules often depend on other modules for common functionality. When you load a module with modprobe, it automatically loads dependencies first:

module_deps.sh
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# View module dependencies
$ modprobe --show-depends nvidia
insmod /lib/modules/6.2.0/kernel/drivers/video/fbdev/core/fb.ko
insmod /lib/modules/6.2.0/kernel/drivers/gpu/drm/drm.ko
insmod /lib/modules/6.2.0/kernel/drivers/gpu/drm/drm_kms_helper.ko
insmod /lib/modules/6.2.0/updates/dkms/nvidia.ko
 
# Module dependency file
$ head /lib/modules/$(uname -r)/modules.dep
kernel/arch/x86/crypto/aesni-intel.ko: kernel/crypto/aes_generic.ko
kernel/drivers/gpu/drm/drm.ko: kernel/drivers/video/fbdev/core/fb.ko
 
# Regenerate dependency database after adding modules
$ sudo depmod -a

Module Signing and Security

Interrupt Handling in Drivers

The Two-Half Interrupt Model:

Modern drivers split interrupt handling into two parts:

Top Half (Hardirq)

•Runs immediately on interrupt
•Interrupts disabled (atomic context)
•Must be extremely fast
•Cannot sleep or allocate memory
•Acknowledges interrupt to hardware
•Schedules bottom half

Bottom Half (Softirq/Tasklet/Workqueue)

•Runs after top half completes
•Interrupts re-enabled
•Can do substantial work
•Different mechanisms available
•Softirq: High-priority, networking
•Workqueue: Can sleep, most flexible

interrupt_handler.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
#include <linux/interrupt.h>
#include <linux/workqueue.h>
 
struct mydev_data {
    struct work_struct work;
    void __iomem *regs;
    spinlock_t lock;
    u32 pending_data;
};
 
/*
 * Top Half: Hardirq handler - runs with interrupts disabled
 * MUST be fast! Just acknowledge interrupt and schedule bottom half.
 */
static irqreturn_t mydev_irq_handler(int irq, void *dev_id)
{
    struct mydev_data *dev = dev_id;
    u32 status;
    
    /* Read interrupt status register */
    status = ioread32(dev->regs + STATUS_REG);
    
    /* Check if this interrupt is for us (shared interrupts) */
    if (!(status & OUR_INTERRUPT_FLAG))
        return IRQ_NONE;  /* Not our interrupt */
    
    /* Acknowledge interrupt to hardware */
    iowrite32(status, dev->regs + STATUS_REG);
    
    /* Save any critical data under spinlock */
    spin_lock(&dev->lock);
    dev->pending_data = ioread32(dev->regs + DATA_REG);
    spin_unlock(&dev->lock);
    
    /* Schedule bottom half for heavy processing */
    schedule_work(&dev->work);
    
    return IRQ_HANDLED;  /* We handled this interrupt */
}
 
/*
 * Bottom Half: Workqueue - runs in process context
 * Can sleep, allocate memory, take semaphores, etc.
 */
static void mydev_work_handler(struct work_struct *work)
{
    struct mydev_data *dev = container_of(work, struct mydev_data, work);
    u32 data;
    
    /* Get data saved by top half */
    spin_lock_irq(&dev->lock);
    data = dev->pending_data;
    spin_unlock_irq(&dev->lock);
    
    /* Process the data - can do time-consuming work here */
    process_device_data(data);
    
    /* Can allocate memory */
    void *buffer = kmalloc(PAGE_SIZE, GFP_KERNEL);
    
    /* Can sleep */
    msleep(10);
    
    kfree(buffer);
}
 
/*
 * Register interrupt handler during probe
 */
static int mydev_setup_irq(struct mydev_data *dev, int irq)
{
    int ret;
    
    /* Initialize work structure */
    INIT_WORK(&dev->work, mydev_work_handler);
    spin_lock_init(&dev->lock);
    
    /* Request IRQ
     * IRQF_SHARED: Can share IRQ line with other devices
     * handler: Top half function
     * dev: Passed to handler as dev_id
     */
    ret = request_irq(irq, mydev_irq_handler,
                      IRQF_SHARED, "mydevice", dev);
    if (ret) {
        pr_err("Failed to request IRQ %d: %d\n", irq, ret);
        return ret;
    }
    
    return 0;
}

Common Interrupt Handler Mistakes

Common Driver Bugs and Pitfalls

Leading Causes of Driver Bugs:

Common Driver Bug Categories
Bug Type	Cause	Typical Symptom
Race conditions	Missing or incorrect locking	Intermittent crashes, data corruption
Memory leaks	Forgetting to free allocated memory	Gradual memory exhaustion
Use-after-free	Accessing freed memory	Crashes, security vulnerabilities
Deadlocks	Inconsistent lock ordering	System hangs
Buffer overflows	Unchecked array bounds	Crashes, arbitrary code execution
Missing error handling	Not checking return values	Silent failures, corrupted state
DMA errors	Wrong addresses, missing sync	Data corruption, crashes
Sleeping in atomic context	Using wrong APIs	Scheduling-while-atomic panics

Why Are Drivers So Buggy?

•Complexity — Hardware is complex, with undocumented quirks and ambiguous specifications
•Concurrency — Drivers face interrupts, multiple CPUs, and preemption simultaneously
•Testing difficulty — Full testing requires real hardware in various configurations
•Tight schedules — Hardware vendors rush drivers to ship with new products
•Kernel expertise — Driver developers may not fully understand kernel internals
•Legacy code — Old drivers are often copied and modified rather than rewritten

driver_bugs_examples.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
/*
 * Examples of common driver bugs and their fixes
 */
 
/* BUG 1: Race condition - no locking */
/* BAD: */
int read_counter(struct device_data *dev) {
    return dev->counter++;  /* Race if multiple CPUs! */
}
/* GOOD: */
int read_counter(struct device_data *dev) {
    unsigned long flags;
    int val;
    spin_lock_irqsave(&dev->lock, flags);
    val = dev->counter++;
    spin_unlock_irqrestore(&dev->lock, flags);
    return val;
}
 
/* BUG 2: Memory leak on error path */
/* BAD: */
int probe(struct device *dev) {
    buf1 = kmalloc(100, GFP_KERNEL);
    buf2 = kmalloc(100, GFP_KERNEL);
    if (!buf2)
        return -ENOMEM;  /* Leaked buf1! */
    /* ... */
}
/* GOOD: */
int probe(struct device *dev) {
    buf1 = kmalloc(100, GFP_KERNEL);
    if (!buf1)
        return -ENOMEM;
    buf2 = kmalloc(100, GFP_KERNEL);
    if (!buf2) {
        kfree(buf1);
        return -ENOMEM;
    }
    /* ... */
}
 
/* BUG 3: Sleeping in atomic context */
/* BAD: */
static irqreturn_t irq_handler(int irq, void *dev_id) {
    struct data *buf = kmalloc(100, GFP_KERNEL);  /* WRONG! Can sleep */
    /* ... */
}
/* GOOD: */
static irqreturn_t irq_handler(int irq, void *dev_id) {
    struct data *buf = kmalloc(100, GFP_ATOMIC);  /* OK: won't sleep */
    /* ... */
}
 
/* BUG 4: Missing DMA synchronization */
/* BAD: */
dma_map_single(dev, buf, size, DMA_FROM_DEVICE);
start_dma_transfer();
/* Read buf immediately - data may not be there yet! */
/* GOOD: */
dma_map_single(dev, buf, size, DMA_FROM_DEVICE);
start_dma_transfer();
wait_for_dma_complete();
dma_sync_single_for_cpu(dev, dma_addr, size, DMA_FROM_DEVICE);
/* Now safe to read buf */

Debugging Driver Issues

User-Space Drivers

User-Space Driver Frameworks:

UIO (Userspace I/O): Simple framework for basic devices
VFIO (Virtual Function I/O): Full-featured framework supporting IOMMU and SR-IOV

Advantages of User-Space Drivers

•Crashes don't bring down the kernel
•Easier debugging with standard tools
•No kernel rebuild for changes
•Use any programming language
•Full memory protection
•Easier to test and deploy

Disadvantages

•Higher interrupt latency
•More context switch overhead
•Requires IOMMU for DMA safety
•Can't integrate with kernel subsystems
•Not suitable for all devices
•Requires root or special permissions

DPDK and High-Performance Networking:

DPDK works by:

Binding NICs to VFIO/UIO (removing from kernel control)
Mapping device memory into user space
Polling hardware directly (no interrupts)
Using huge pages for DMA buffers
Bypassing the kernel network stack entirely

vfio_setup.sh
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# Example: Binding a device to VFIO for user-space use
 
# 1. Load VFIO modules
$ sudo modprobe vfio-pci
 
# 2. Find device PCI address
$ lspci -D | grep Network
0000:03:00.0 Ethernet controller: Intel Corporation ...
 
# 3. Get current driver
$ ls -la /sys/bus/pci/devices/0000:03:00.0/driver
lrwxrwxrwx 1 root root 0 Jan 15 10:00 driver -> ../../../../bus/pci/drivers/igb
 
# 4. Get device IDs
$ lspci -n -s 0000:03:00.0
0000:03:00.0 0200: 8086:1533 (rev 03)
 
# 5. Unbind from current driver
$ echo 0000:03:00.0 | sudo tee /sys/bus/pci/devices/0000:03:00.0/driver/unbind
 
# 6. Bind to vfio-pci
$ echo "8086 1533" | sudo tee /sys/bus/pci/drivers/vfio-pci/new_id
 
# 7. Open from user space (in your application)
# fd = open("/dev/vfio/group", ...);
# mmap() device registers
# Read/write directly to control the device
 
# Note: Real VFIO usage requires IOMMU setup and group management

FUSE: User-Space File Systems

Summary: Device Drivers

Key Takeaways

•Drivers translate abstractions to hardware — They convert generic I/O operations to device-specific commands, handling all hardware details.
•Drivers implement standard interfaces — The file_operations structure (for char/block devices) or subsystem-specific interfaces provide the connection point with the kernel.
•Drivers are organized by subsystems — Different device types (block, network, USB, etc.) have their own frameworks with shared infrastructure.
•Modules enable dynamic loading — Drivers can be loaded and unloaded at runtime, supporting hot-plug and reducing memory usage.
•Interrupt handling uses the two-half model — Fast top-half acknowledges the interrupt; slower bottom-half does the real work.
•Drivers are bug-prone — Race conditions, memory errors, and sleeping in atomic context are common problems.
•User-space drivers offer an alternative — VFIO, UIO, and FUSE enable safer driver development for suitable devices.

What's Next:

Page Complete