Driver Architecture - Device Drivers | OneNoughtOne

0/236

Operating SystemsDevice Drivers

Device Drivers

LevelAdvanced

Duration90 mins

TopicDevice Drivers

1 / 5

Driver Architecture

The Silent Translators of Computing

Every time you press a key, move your mouse, or save a file to disk, an intricate dance occurs between hardware and software—a dance choreographed by device drivers. These essential pieces of software are the unsung heroes of computing, translating the abstract operations requested by applications and the operating system into the precise electrical signals that hardware understands, and vice versa.

Without device drivers, your operating system would be blind to the existence of your hardware. A USB keyboard would be nothing but a collection of circuits. A graphics card would sit idle, incapable of rendering a single pixel. Device drivers are the critical bridge that makes modern computing possible.

What You Will Learn

By the end of this page, you will understand the fundamental architecture of device drivers, including the layered structure that separates concerns, the components that make up a driver, the design patterns that ensure reliability and maintainability, and how drivers integrate with the operating system kernel. This knowledge forms the foundation for understanding driver development, debugging, and optimization.

The Role of Device Drivers

To truly appreciate driver architecture, we must first understand the fundamental problem drivers solve. Operating systems are designed to be hardware-agnostic—they provide consistent abstractions (files, processes, network connections) regardless of the underlying hardware. Yet hardware is extraordinarily diverse: thousands of different devices from hundreds of manufacturers, each with unique characteristics, protocols, and quirks.

The Abstraction Challenge:

Consider the simple act of writing data to storage:

A magnetic hard drive requires precise timing of head movements, platter rotations, and magnetic field manipulations
An SSD translates logical addresses to physical NAND flash cells, managing wear leveling and garbage collection
A network-attached storage device communicates over TCP/IP, handling network latency and packet loss
A RAM disk operates entirely in memory with no persistent storage concerns

From the application's perspective, all of these should behave identically: you call write() and data gets stored. Device drivers make this abstraction possible.

Device Driver Responsibilities
Responsibility	Description	Example
Hardware Abstraction	Hide device-specific details behind standard interfaces	All storage devices expose read/write block operations regardless of physical technology
Device Initialization	Configure hardware to operational state during boot or hot-plug	Setting up DMA channels, allocating interrupt vectors, configuring registers
Request Translation	Convert high-level I/O requests to device-specific commands	Converting filesystem block writes to SATA commands with sector addresses
Interrupt Handling	Respond to hardware events asynchronously	Processing completion notifications when DMA transfers finish
Power Management	Control device power states for efficiency	Suspending unused devices, handling system sleep/resume
Error Handling	Detect and recover from hardware failures	Retrying failed operations, reporting unrecoverable errors to the kernel
Synchronization	Manage concurrent access to shared hardware	Serializing requests when hardware can only process one at a time

The Driver as a Contract

Think of a device driver as a bilateral contract: it promises to implement a standard interface that the kernel expects (the 'upward' interface), while simultaneously speaking the hardware's native language (the 'downward' interface). The quality of a driver depends on how well it fulfills both sides of this contract.

Layered Driver Architecture

Modern operating systems employ a layered driver architecture that separates functionality into distinct levels, each with specific responsibilities. This layering provides several critical benefits:

Code Reuse: Common functionality is implemented once in higher layers and shared by all lower-layer drivers
Simplified Development: Driver authors only need to implement device-specific behavior, not general I/O infrastructure
Flexibility: Intermediate layers can be inserted or modified without affecting other components
Reliability: Clear boundaries enable better testing and fault isolation

The I/O Stack:

In most operating systems, the I/O subsystem forms a stack of layers, with requests flowing downward toward hardware and responses flowing upward toward applications. Each layer adds value by handling specific concerns.

Converting Mermaid diagram...

Layer Descriptions:

1. Virtual File System (VFS) / I/O Manager: The topmost kernel layer that presents a unified interface to user space. The VFS provides abstraction for files, directories, and I/O operations regardless of the underlying storage or device type. It routes requests to appropriate lower layers based on device type and mounted filesystems.

2. File System / Protocol Layer: Implements logical structure on top of raw storage. For block devices, this might be ext4, NTFS, or XFS. For network devices, this could be TCP/IP or other protocol stacks. This layer translates file operations into block or packet operations.

3. Block Layer / Buffer Cache: Manages I/O scheduling, caching, and queuing for block devices. It reorders and merges requests for efficiency, implements I/O scheduling algorithms, and maintains the buffer cache for frequently accessed data.

4. Device Driver: The device-specific layer that translates abstract operations into hardware commands. This is where the knowledge of a particular device's registers, protocols, and behaviors resides.

5. Hardware Abstraction Layer (HAL): Provides a consistent interface to basic hardware mechanisms like interrupt controllers, DMA engines, and bus access. Not all operating systems have an explicit HAL—some embed this functionality in drivers.

Platform Variations

The exact layering varies by operating system. Windows uses a highly structured driver stack with filter drivers and class drivers. Linux has a more flexible model with multiple subsystems (block, network, character, USB). The concepts remain consistent, but implementation details differ significantly.

Driver Component Structure

A well-structured device driver consists of several distinct components, each handling specific aspects of driver functionality. Understanding these components is essential for both driver development and debugging.

Core Driver Components

•Initialization and Cleanup Routines — Functions called when the driver is loaded (init/probe) and unloaded (exit/remove). Handle resource allocation, hardware detection, device registration, and cleanup on shutdown.
•Device Operations Structure — A table of function pointers implementing the driver's interface: open, close, read, write, ioctl, mmap, and device-specific operations. This is the contract with the kernel.
•Interrupt Service Routines (ISRs) — Handlers invoked by hardware interrupts. Must execute quickly, typically just acknowledging the interrupt and scheduling deferred work (bottom halves, work queues, or tasklets).
•Deferred Processing Handlers — Logic that was too time-consuming for the ISR, executed in a safer context. Includes work queues, tasklets, softirqs, or threaded interrupt handlers.
•Power Management Callbacks — Functions for suspend, resume, and runtime power management. Critical for mobile devices and energy efficiency.
•Device State Management — Data structures maintaining device state, configuration, and per-device private data. Often includes status registers, configuration parameters, and queued requests.
•Error Handling Logic — Detection and recovery from hardware errors, timeout handling, and retry mechanisms. Includes logging and reporting facilities for diagnostics.

driver-structure-example.c
Linux Kernel Driver Structure
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
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
/* Example: Simplified Linux Character Device Driver Structure */
 
#include <linux/module.h>
#include <linux/fs.h>
#include <linux/cdev.h>
#include <linux/interrupt.h>
#include <linux/pm.h>
 
/* Per-device private data */
struct mydev_data {
    struct cdev cdev;           /* Character device structure */
    void __iomem *regs;         /* Memory-mapped registers */
    int irq;                    /* Assigned interrupt number */
    spinlock_t lock;            /* Protecting concurrent access */
    wait_queue_head_t wait_q;   /* For blocking operations */
    struct work_struct work;    /* Deferred work */
    bool device_ready;          /* Device state flag */
};
 
/* File operations - the upward interface to kernel/userspace */
static const struct file_operations mydev_fops = {
    .owner   = THIS_MODULE,
    .open    = mydev_open,      /* Called when file is opened */
    .release = mydev_release,   /* Called when file is closed */
    .read    = mydev_read,      /* Read data from device */
    .write   = mydev_write,     /* Write data to device */
    .unlocked_ioctl = mydev_ioctl,  /* Device-specific control */
    .mmap    = mydev_mmap,      /* Memory mapping */
    .poll    = mydev_poll,      /* For select/poll/epoll */
};
 
/* Interrupt handler - top half, runs in interrupt context */
static irqreturn_t mydev_isr(int irq, void *dev_id)
{
    struct mydev_data *data = dev_id;
    u32 status;
    
    /* Read interrupt status register */
    status = ioread32(data->regs + STATUS_REG);
    
    /* Check if this interrupt is ours */
    if (!(status & OUR_INTERRUPT_FLAG))
        return IRQ_NONE;  /* Not our interrupt */
    
    /* Acknowledge the interrupt in hardware */
    iowrite32(status, data->regs + STATUS_REG);
    
    /* Schedule deferred work for heavy processing */
    schedule_work(&data->work);
    
    return IRQ_HANDLED;
}
 
/* Deferred work - bottom half, runs in process context */
static void mydev_work_handler(struct work_struct *work)
{
    struct mydev_data *data = container_of(work, struct mydev_data, work);
    
    /* Perform time-consuming processing here */
    /* Can sleep, allocate memory, etc. */
    
    /* Wake up any waiting processes */
    wake_up_interruptible(&data->wait_q);
}
 
/* Power management operations */
static int mydev_suspend(struct device *dev)
{
    struct mydev_data *data = dev_get_drvdata(dev);
    
    /* Save device state and power down */
    disable_irq(data->irq);
    /* Save any hardware registers if needed */
    /* Put device in low-power state */
    
    return 0;
}
 
static int mydev_resume(struct device *dev)
{
    struct mydev_data *data = dev_get_drvdata(dev);
    
    /* Restore device state and power up */
    /* Reinitialize hardware registers */
    enable_irq(data->irq);
    
    return 0;
}
 
static const struct dev_pm_ops mydev_pm_ops = {
    .suspend = mydev_suspend,
    .resume  = mydev_resume,
};
 
/* Module initialization - called when driver is loaded */
static int __init mydev_init(void)
{
    /* Allocate device numbers, register with kernel */
    /* Initialize data structures */
    /* Register the character device */
    return 0;
}
 
/* Module cleanup - called when driver is unloaded */
static void __exit mydev_exit(void)
{
    /* Unregister device, free resources */
    /* Release device numbers */
}
 
module_init(mydev_init);
module_exit(mydev_exit);
 
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Example Author");
MODULE_DESCRIPTION("Illustrative Device Driver Structure");

Kernel Context Matters

Understanding execution context is critical for driver development. Interrupt handlers run with interrupts disabled (or at elevated priority) and cannot sleep or perform certain operations. Process context code can sleep but must be aware of concurrency. Mixing these up causes kernel panics, deadlocks, and subtle bugs.

Driver Models and Subsystems

Modern operating systems organize drivers into subsystems based on device class. Each subsystem provides a framework that handles common functionality, allowing individual drivers to focus on device-specific behavior. This approach dramatically reduces code duplication and ensures consistent behavior across similar devices.

Major Driver Subsystems
Subsystem	Device Types	Key Abstractions	Common Interface
Block	HDDs, SSDs, USB drives, RAM disks	Sectors, queues, schedulers	read_block(), write_block(), request handling
Character	Serial ports, keyboards, custom devices	Byte streams, poll/select	open(), read(), write(), ioctl()
Network	Ethernet, WiFi, virtual NICs	Packets, buffers, protocols	ndo_start_xmit(), NAPI polling
Graphics/DRM	GPUs, display controllers	Framebuffers, KMS, GEM	Mode setting, page flipping, buffer management
USB	USB devices of all classes	Endpoints, transfers, URBs	probe(), disconnect(), class-specific ops
Input	Keyboards, mice, touchscreens	Events, input reports	input_report_key(), input_sync()
Sound/ALSA	Sound cards, audio devices	PCM streams, controls	trigger(), pointer(), hw_params()

The Layered Subsystem Model:

Most subsystems implement a hierarchical model with multiple layers:

Core Layer: Provides the fundamental abstractions and interfaces for the subsystem. For block devices, this is the block layer that manages request queues and I/O scheduling. For USB, it's the USB core that handles enumeration and the basic protocol.

Class Drivers: Implement behavior common to a class of devices. A USB mass storage class driver handles all USB storage devices, translating between USB transfers and block I/O. Class drivers may themselves form hierarchies.

Miniport/Hardware Drivers: The lowest layer, implementing device-specific operations. These drivers are often small, containing only the code needed to program a specific device's registers and handle its peculiarities.

Converting Mermaid diagram...

Framework Benefits

Subsystem frameworks provide enormous value: hot-plug support, power management integration, sysfs/procfs exposure, consistent error handling, and tested code paths. A new driver leveraging a mature subsystem inherits years of bug fixes and optimizations.

Registration and Discovery

A fundamental challenge in driver architecture is matching drivers to devices. When the system boots or a device is hot-plugged, how does the operating system know which driver to use? Modern systems solve this through a sophisticated registration and discovery mechanism.

The Driver-Device Matching Problem:

Consider USB enumeration: when a USB device is connected, the host controller detects it and reads its descriptors. These descriptors include vendor ID, product ID, device class, and other identifying information. The kernel must find a driver capable of handling this specific device—from potentially hundreds of loaded drivers.

Driver Registration

•Driver declares a match table listing supported devices
•Match criteria include vendor/product IDs, class codes, or compatible strings
•Driver registers with appropriate bus subsystem
•Kernel maintains registry of all registered drivers
•Generic/fallback drivers can match broad device classes

Device Discovery

•Bus enumeration detects new devices
•Device descriptors are read from hardware
•Kernel searches for matching drivers
•Matching algorithm considers specificity (exact match beats generic)
•Driver's probe() function is called to claim the device

device-matching.c
Linux Driver ID Tables
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
/* Example: PCI Device ID Table */
static const struct pci_device_id mydriver_pci_tbl[] = {
    /* Exact match: specific vendor and device */
    { PCI_DEVICE(0x8086, 0x1234) },
    
    /* Multiple devices from same vendor */
    { PCI_DEVICE(0x8086, 0x5678) },
    { PCI_DEVICE(0x8086, 0x9ABC) },
    
    /* Match by class code (any vendor's SATA controller) */
    { PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA, 0xFFFFFF) },
    
    /* End of table marker */
    { 0, }
};
MODULE_DEVICE_TABLE(pci, mydriver_pci_tbl);
 
/* Example: USB Device ID Table */
static const struct usb_device_id mydriver_usb_tbl[] = {
    /* Match specific vendor/product */
    { USB_DEVICE(0x1234, 0x5678) },
    
    /* Match any device of a class (mass storage) */
    { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, 
                         USB_SC_SCSI, USB_PR_BULK) },
    
    { }
};
MODULE_DEVICE_TABLE(usb, mydriver_usb_tbl);
 
/* Example: Device Tree / Platform matching (embedded systems) */
static const struct of_device_id mydriver_of_match[] = {
    { .compatible = "vendor,device-v1" },
    { .compatible = "vendor,device-v2" },
    { }
};
MODULE_DEVICE_TABLE(of, mydriver_of_match);

The Probe Function:

When a match is found, the kernel calls the driver's probe() function, passing information about the device. The probe function is responsible for:

Validating the device — Confirming the device is actually compatible and functional
Allocating resources — Memory, I/O ports, DMA channels, interrupt lines
Initializing hardware — Resetting the device, configuring registers, enabling features
Registering with higher layers — Making the device visible (e.g., creating /dev nodes)
Setting up interrupt handlers — Installing ISRs for device interrupts

If probe succeeds, the driver owns the device. If it fails (returns negative error code), the kernel may try other matching drivers or report the device as unclaimed.

Hot-Plug and Hot-Remove

Modern buses like USB and PCIe support hot-plugging. When a device is removed, the kernel calls the driver's remove() function, which must release all resources, stop all operations, and unregister from higher layers. Proper cleanup is essential to prevent memory leaks, dangling pointers, and kernel crashes.

Execution Contexts

Understanding execution contexts is fundamental to driver architecture. Driver code can run in several different contexts, each with its own rules, restrictions, and appropriate use cases. Violating these rules leads to deadlocks, crashes, and subtle corruption.

Why Context Matters:

The kernel must remain responsive and stable at all times. Certain operations—like sleeping or allocating large amounts of memory—are only safe when the kernel can safely suspend the current operation. In interrupt context, there's no 'current process' to suspend, making such operations catastrophic.

Driver Execution Contexts
Context	When Entered	What's Allowed	What's Forbidden
Process Context	System calls from user space (read, write, ioctl)	Sleeping, memory allocation with GFP_KERNEL, direct user memory access	Holding spinlocks across sleeps
Hard Interrupt Context	Hardware interrupt arrives (ISR)	Quick register access, atomic operations, scheduling deferred work	Sleeping, mutex locks, prolonged execution
Soft Interrupt Context	Softirqs, tasklets	Non-sleeping operations, network packet processing	Sleeping, mutex acquisition
Work Queue Context	Kernel worker threads	Full process context capabilities, can sleep	Same restrictions as process context
Kernel Thread Context	Dedicated kernel threads (e.g., block I/O)	Full process context, persistent state	Must check for kthread_should_stop()

The Split-Handler Pattern:

Most hardware drivers use a split-handler approach to balance responsiveness with processing needs:

Top Half (Interrupt Handler):

Executes immediately when hardware signals
Runs with interrupts disabled or at elevated priority
Must be extremely fast (microseconds)
Only acknowledges the interrupt Scheduling deferred work
No sleeping, no blocking, minimal processing

Bottom Half (Deferred Handler):

Runs later, in a safer context
Can take much longer (milliseconds to seconds)
Can allocate memory, access user space, acquire mutexes
Implemented via work queues, tasklets, or threaded interrupts

This pattern ensures that interrupts are acknowledged quickly (preventing hardware timeouts and cascaded interrupts) while still allowing complex processing.

split-handler.c
Split Interrupt Handling
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
/* Top Half - Runs in hard interrupt context */
static irqreturn_t my_isr(int irq, void *dev_id)
{
    struct my_device *dev = dev_id;
    u32 status;
    
    /* Read status - fast register access */
    status = readl(dev->regs + STATUS);
    
    if (!(status & MY_INTERRUPT_PENDING))
        return IRQ_NONE; /* Not our interrupt */
    
    /* Acknowledge immediately */
    writel(status, dev->regs + STATUS);
    
    /* Save status for bottom half */
    dev->pending_status = status;
    
    /* Schedule bottom half processing */
    if (status & DATA_READY)
        schedule_work(&dev->data_work);
    
    if (status & ERROR_FLAG)
        schedule_work(&dev->error_work);
    
    return IRQ_HANDLED;
}
 
/* Bottom Half - Runs in process context */
static void my_data_work_func(struct work_struct *work)
{
    struct my_device *dev = container_of(work, 
                                         struct my_device, 
                                         data_work);
    void *buffer;
    
    /* Now we can sleep for memory allocation */
    buffer = kmalloc(BUFFER_SIZE, GFP_KERNEL);
    if (!buffer) {
        dev_err(dev->dev, "Allocation failed
");
        return;
    }
    
    /* Perform actual data processing */
    mutex_lock(&dev->data_mutex);  /* Can sleep! */
    process_received_data(dev, buffer);
    mutex_unlock(&dev->data_mutex);
    
    /* Wake up waiting user processes */
    wake_up_interruptible(&dev->read_wait);
    
    kfree(buffer);
}

Context Violation = System Crash

Calling a sleeping function from interrupt context will cause a kernel BUG or panic. Common violations include using mutex_lock() (use spin_lock() instead), calling kmalloc with GFP_KERNEL (use GFP_ATOMIC), or using copy_to_user() (defer to work queue). Always know your context.

Synchronization in Drivers

Device drivers face extreme concurrency challenges. Multiple processors may access driver data simultaneously. Interrupt handlers may fire while driver code is executing. User processes may issue overlapping requests. Proper synchronization is not optional—it's essential for system stability.

Sources of Concurrency:

SMP (Symmetric Multiprocessing): Multiple CPUs can execute driver code simultaneously
Preemption: The scheduler can preempt driver code to run other tasks
Interrupts: Hardware interrupts can occur at any time, even during critical sections
Kernel Threads: Work queues and other threads run independently
User Processes: Multiple processes may access the device concurrently

Synchronization Primitives in Drivers
Primitive	Use Case	Can Sleep?	Performance Impact
Spinlock	Short critical sections, interrupt context safe	No	Low for uncontended; high contention causes CPU spinning
Mutex	Long critical sections, only process context	Yes	Efficient for contended locks; lets CPU do other work
Semaphore	Limiting concurrent access count	Yes	Similar to mutex with configurable count
RW Lock (Reader-Writer)	Read-mostly data structures	Depends on variant	Allows concurrent readers; writers exclusive
RCU (Read-Copy-Update)	Read-frequently, write-rarely structures	Readers don't block	Optimal for read-heavy workloads; complex semantics
Atomic Operations	Simple counters and flags	No	Very low; hardware-level atomicity
Memory Barriers	Ordering memory operations	No	Required for lock-free algorithms

Choosing the Right Primitive:

Use spinlocks when:

The critical section is very short (microseconds)
The code may run in interrupt context
You're protecting simple data structures

Use mutexes when:

The critical section may be long or variable length
The code might need to sleep (memory allocation, I/O waits)
You're only ever in process context

Use RCU when:

Readers vastly outnumber writers
You can tolerate eventual consistency for readers
Maximum read performance is critical

Lock Ordering:

To prevent deadlocks, always acquire locks in a consistent, documented order. If lock A must sometimes be held while acquiring lock B, then every code path must acquire A before B. Never invert order based on circumstance.

driver-synchronization.c
Common Synchronization Patterns
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
/* Pattern 1: Spinlock for hardware register access */
static void write_device_register(struct my_device *dev, 
                                   u32 reg, u32 value)
{
    unsigned long flags;
    
    spin_lock_irqsave(&dev->lock, flags);  /* Disable interrupts, take lock */
    writel(value, dev->regs + reg);
    spin_unlock_irqrestore(&dev->lock, flags);  /* Restore interrupts, release */
}
 
/* Pattern 2: Mutex for file operations */
static ssize_t mydev_read(struct file *file, char __user *buf,
                          size_t count, loff_t *ppos)
{
    struct my_device *dev = file->private_data;
    ssize_t ret;
    
    /* Can sleep - appropriate for process context */
    if (mutex_lock_interruptible(&dev->io_mutex))
        return -ERESTARTSYS;
    
    /* Perform I/O operation that may wait */
    ret = wait_event_interruptible(dev->wait_queue,
                                   has_data_available(dev));
    if (ret == 0)
        ret = copy_data_to_user(dev, buf, count);
    
    mutex_unlock(&dev->io_mutex);
    return ret;
}
 
/* Pattern 3: Protecting shared state between ISR and process context */
static void update_device_state(struct my_device *dev, u32 new_state)
{
    unsigned long flags;
    
    spin_lock_irqsave(&dev->state_lock, flags);
    dev->state = new_state;
    dev->state_changed = true;
    spin_unlock_irqrestore(&dev->state_lock, flags);
    
    /* Wake up anyone waiting on state change */
    wake_up_interruptible(&dev->state_wait);
}
 
static irqreturn_t mydev_isr(int irq, void *dev_id)
{
    struct my_device *dev = dev_id;
    u32 status;
    
    spin_lock(&dev->state_lock);  /* IRQ already disabled */
    status = readl(dev->regs + STATUS);
    if (status & STATE_CHANGED)
        dev->state_changed = true;
    spin_unlock(&dev->state_lock);
    
    return IRQ_HANDLED;
}

The Deadlock Danger

Holding a spinlock while calling a function that might acquire the same lock (directly or indirectly) causes a deadlock on single-CPU systems and a livelock on SMP. Always use _irqsave variants when the lock might be used in interrupt handlers. Document lock ordering in comments.

Summary: Driver Architecture

We've explored the foundational concepts of device driver architecture. Let's consolidate the key takeaways:

Key Takeaways

•Drivers bridge hardware and software — They translate abstract OS operations into device-specific commands and vice versa, enabling hardware abstraction.
•Layered architecture enables code reuse — From VFS through device drivers, each layer handles specific concerns, reducing duplication and simplifying development.
•Drivers consist of well-defined components — Initialization, operations structure, interrupt handlers, deferred processing, power management, and error handling.
•Subsystems provide frameworks — Block, character, network, and other subsystems reduce boilerplate and ensure consistent behavior across device classes.
•Registration and discovery match drivers to devices — ID tables and probe functions enable automatic device detection and configuration.
•Execution context determines valid operations — Interrupt context forbids sleeping; process context allows it. Violations cause crashes.
•Synchronization is mandatory — SMP, preemption, and interrupts create concurrency that must be handled with appropriate locking primitives.

What's Next:

With architecture fundamentals established, we'll next explore the driver interface—the contract between drivers and the kernel. We'll examine file operations, ioctl commands, memory mapping, and the mechanisms drivers use to communicate with user space and other kernel subsystems.

Page Complete

You now understand the architectural foundations of device drivers—their role, structure, and the design principles that make them work. This knowledge is essential for understanding how operating systems interact with hardware and for developing or debugging drivers.

Operating SystemsDevice Drivers

Device Drivers

LevelAdvanced

Duration90 mins

TopicDevice Drivers

1 / 5

Driver Architecture

The Silent Translators of Computing

What You Will Learn

The Role of Device Drivers

The Abstraction Challenge:

Consider the simple act of writing data to storage:

A magnetic hard drive requires precise timing of head movements, platter rotations, and magnetic field manipulations
An SSD translates logical addresses to physical NAND flash cells, managing wear leveling and garbage collection
A network-attached storage device communicates over TCP/IP, handling network latency and packet loss
A RAM disk operates entirely in memory with no persistent storage concerns

From the application's perspective, all of these should behave identically: you call write() and data gets stored. Device drivers make this abstraction possible.

Device Driver Responsibilities
Responsibility	Description	Example
Hardware Abstraction	Hide device-specific details behind standard interfaces	All storage devices expose read/write block operations regardless of physical technology
Device Initialization	Configure hardware to operational state during boot or hot-plug	Setting up DMA channels, allocating interrupt vectors, configuring registers
Request Translation	Convert high-level I/O requests to device-specific commands	Converting filesystem block writes to SATA commands with sector addresses
Interrupt Handling	Respond to hardware events asynchronously	Processing completion notifications when DMA transfers finish
Power Management	Control device power states for efficiency	Suspending unused devices, handling system sleep/resume
Error Handling	Detect and recover from hardware failures	Retrying failed operations, reporting unrecoverable errors to the kernel
Synchronization	Manage concurrent access to shared hardware	Serializing requests when hardware can only process one at a time

The Driver as a Contract

Layered Driver Architecture

Code Reuse: Common functionality is implemented once in higher layers and shared by all lower-layer drivers
Simplified Development: Driver authors only need to implement device-specific behavior, not general I/O infrastructure
Flexibility: Intermediate layers can be inserted or modified without affecting other components
Reliability: Clear boundaries enable better testing and fault isolation

The I/O Stack:

Converting Mermaid diagram...

Layer Descriptions:

Platform Variations

Driver Component Structure

Core Driver Components

•Initialization and Cleanup Routines — Functions called when the driver is loaded (init/probe) and unloaded (exit/remove). Handle resource allocation, hardware detection, device registration, and cleanup on shutdown.
•Device Operations Structure — A table of function pointers implementing the driver's interface: open, close, read, write, ioctl, mmap, and device-specific operations. This is the contract with the kernel.
•Interrupt Service Routines (ISRs) — Handlers invoked by hardware interrupts. Must execute quickly, typically just acknowledging the interrupt and scheduling deferred work (bottom halves, work queues, or tasklets).
•Deferred Processing Handlers — Logic that was too time-consuming for the ISR, executed in a safer context. Includes work queues, tasklets, softirqs, or threaded interrupt handlers.
•Power Management Callbacks — Functions for suspend, resume, and runtime power management. Critical for mobile devices and energy efficiency.
•Device State Management — Data structures maintaining device state, configuration, and per-device private data. Often includes status registers, configuration parameters, and queued requests.
•Error Handling Logic — Detection and recovery from hardware errors, timeout handling, and retry mechanisms. Includes logging and reporting facilities for diagnostics.

driver-structure-example.c
Linux Kernel Driver Structure
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
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
/* Example: Simplified Linux Character Device Driver Structure */
 
#include <linux/module.h>
#include <linux/fs.h>
#include <linux/cdev.h>
#include <linux/interrupt.h>
#include <linux/pm.h>
 
/* Per-device private data */
struct mydev_data {
    struct cdev cdev;           /* Character device structure */
    void __iomem *regs;         /* Memory-mapped registers */
    int irq;                    /* Assigned interrupt number */
    spinlock_t lock;            /* Protecting concurrent access */
    wait_queue_head_t wait_q;   /* For blocking operations */
    struct work_struct work;    /* Deferred work */
    bool device_ready;          /* Device state flag */
};
 
/* File operations - the upward interface to kernel/userspace */
static const struct file_operations mydev_fops = {
    .owner   = THIS_MODULE,
    .open    = mydev_open,      /* Called when file is opened */
    .release = mydev_release,   /* Called when file is closed */
    .read    = mydev_read,      /* Read data from device */
    .write   = mydev_write,     /* Write data to device */
    .unlocked_ioctl = mydev_ioctl,  /* Device-specific control */
    .mmap    = mydev_mmap,      /* Memory mapping */
    .poll    = mydev_poll,      /* For select/poll/epoll */
};
 
/* Interrupt handler - top half, runs in interrupt context */
static irqreturn_t mydev_isr(int irq, void *dev_id)
{
    struct mydev_data *data = dev_id;
    u32 status;
    
    /* Read interrupt status register */
    status = ioread32(data->regs + STATUS_REG);
    
    /* Check if this interrupt is ours */
    if (!(status & OUR_INTERRUPT_FLAG))
        return IRQ_NONE;  /* Not our interrupt */
    
    /* Acknowledge the interrupt in hardware */
    iowrite32(status, data->regs + STATUS_REG);
    
    /* Schedule deferred work for heavy processing */
    schedule_work(&data->work);
    
    return IRQ_HANDLED;
}
 
/* Deferred work - bottom half, runs in process context */
static void mydev_work_handler(struct work_struct *work)
{
    struct mydev_data *data = container_of(work, struct mydev_data, work);
    
    /* Perform time-consuming processing here */
    /* Can sleep, allocate memory, etc. */
    
    /* Wake up any waiting processes */
    wake_up_interruptible(&data->wait_q);
}
 
/* Power management operations */
static int mydev_suspend(struct device *dev)
{
    struct mydev_data *data = dev_get_drvdata(dev);
    
    /* Save device state and power down */
    disable_irq(data->irq);
    /* Save any hardware registers if needed */
    /* Put device in low-power state */
    
    return 0;
}
 
static int mydev_resume(struct device *dev)
{
    struct mydev_data *data = dev_get_drvdata(dev);
    
    /* Restore device state and power up */
    /* Reinitialize hardware registers */
    enable_irq(data->irq);
    
    return 0;
}
 
static const struct dev_pm_ops mydev_pm_ops = {
    .suspend = mydev_suspend,
    .resume  = mydev_resume,
};
 
/* Module initialization - called when driver is loaded */
static int __init mydev_init(void)
{
    /* Allocate device numbers, register with kernel */
    /* Initialize data structures */
    /* Register the character device */
    return 0;
}
 
/* Module cleanup - called when driver is unloaded */
static void __exit mydev_exit(void)
{
    /* Unregister device, free resources */
    /* Release device numbers */
}
 
module_init(mydev_init);
module_exit(mydev_exit);
 
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Example Author");
MODULE_DESCRIPTION("Illustrative Device Driver Structure");

Kernel Context Matters

Driver Models and Subsystems

Major Driver Subsystems
Subsystem	Device Types	Key Abstractions	Common Interface
Block	HDDs, SSDs, USB drives, RAM disks	Sectors, queues, schedulers	read_block(), write_block(), request handling
Character	Serial ports, keyboards, custom devices	Byte streams, poll/select	open(), read(), write(), ioctl()
Network	Ethernet, WiFi, virtual NICs	Packets, buffers, protocols	ndo_start_xmit(), NAPI polling
Graphics/DRM	GPUs, display controllers	Framebuffers, KMS, GEM	Mode setting, page flipping, buffer management
USB	USB devices of all classes	Endpoints, transfers, URBs	probe(), disconnect(), class-specific ops
Input	Keyboards, mice, touchscreens	Events, input reports	input_report_key(), input_sync()
Sound/ALSA	Sound cards, audio devices	PCM streams, controls	trigger(), pointer(), hw_params()

The Layered Subsystem Model:

Most subsystems implement a hierarchical model with multiple layers:

Converting Mermaid diagram...

Framework Benefits

Registration and Discovery

The Driver-Device Matching Problem:

Driver Registration

•Driver declares a match table listing supported devices
•Match criteria include vendor/product IDs, class codes, or compatible strings
•Driver registers with appropriate bus subsystem
•Kernel maintains registry of all registered drivers
•Generic/fallback drivers can match broad device classes

Device Discovery

•Bus enumeration detects new devices
•Device descriptors are read from hardware
•Kernel searches for matching drivers
•Matching algorithm considers specificity (exact match beats generic)
•Driver's probe() function is called to claim the device

device-matching.c
Linux Driver ID Tables
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
/* Example: PCI Device ID Table */
static const struct pci_device_id mydriver_pci_tbl[] = {
    /* Exact match: specific vendor and device */
    { PCI_DEVICE(0x8086, 0x1234) },
    
    /* Multiple devices from same vendor */
    { PCI_DEVICE(0x8086, 0x5678) },
    { PCI_DEVICE(0x8086, 0x9ABC) },
    
    /* Match by class code (any vendor's SATA controller) */
    { PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA, 0xFFFFFF) },
    
    /* End of table marker */
    { 0, }
};
MODULE_DEVICE_TABLE(pci, mydriver_pci_tbl);
 
/* Example: USB Device ID Table */
static const struct usb_device_id mydriver_usb_tbl[] = {
    /* Match specific vendor/product */
    { USB_DEVICE(0x1234, 0x5678) },
    
    /* Match any device of a class (mass storage) */
    { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, 
                         USB_SC_SCSI, USB_PR_BULK) },
    
    { }
};
MODULE_DEVICE_TABLE(usb, mydriver_usb_tbl);
 
/* Example: Device Tree / Platform matching (embedded systems) */
static const struct of_device_id mydriver_of_match[] = {
    { .compatible = "vendor,device-v1" },
    { .compatible = "vendor,device-v2" },
    { }
};
MODULE_DEVICE_TABLE(of, mydriver_of_match);

The Probe Function:

When a match is found, the kernel calls the driver's probe() function, passing information about the device. The probe function is responsible for:

Validating the device — Confirming the device is actually compatible and functional
Allocating resources — Memory, I/O ports, DMA channels, interrupt lines
Initializing hardware — Resetting the device, configuring registers, enabling features
Registering with higher layers — Making the device visible (e.g., creating /dev nodes)
Setting up interrupt handlers — Installing ISRs for device interrupts

If probe succeeds, the driver owns the device. If it fails (returns negative error code), the kernel may try other matching drivers or report the device as unclaimed.

Hot-Plug and Hot-Remove

Execution Contexts

Why Context Matters:

Driver Execution Contexts
Context	When Entered	What's Allowed	What's Forbidden
Process Context	System calls from user space (read, write, ioctl)	Sleeping, memory allocation with GFP_KERNEL, direct user memory access	Holding spinlocks across sleeps
Hard Interrupt Context	Hardware interrupt arrives (ISR)	Quick register access, atomic operations, scheduling deferred work	Sleeping, mutex locks, prolonged execution
Soft Interrupt Context	Softirqs, tasklets	Non-sleeping operations, network packet processing	Sleeping, mutex acquisition
Work Queue Context	Kernel worker threads	Full process context capabilities, can sleep	Same restrictions as process context
Kernel Thread Context	Dedicated kernel threads (e.g., block I/O)	Full process context, persistent state	Must check for kthread_should_stop()

The Split-Handler Pattern:

Most hardware drivers use a split-handler approach to balance responsiveness with processing needs:

Top Half (Interrupt Handler):

Executes immediately when hardware signals
Runs with interrupts disabled or at elevated priority
Must be extremely fast (microseconds)
Only acknowledges the interrupt Scheduling deferred work
No sleeping, no blocking, minimal processing

Bottom Half (Deferred Handler):

Runs later, in a safer context
Can take much longer (milliseconds to seconds)
Can allocate memory, access user space, acquire mutexes
Implemented via work queues, tasklets, or threaded interrupts

This pattern ensures that interrupts are acknowledged quickly (preventing hardware timeouts and cascaded interrupts) while still allowing complex processing.

split-handler.c
Split Interrupt Handling
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
/* Top Half - Runs in hard interrupt context */
static irqreturn_t my_isr(int irq, void *dev_id)
{
    struct my_device *dev = dev_id;
    u32 status;
    
    /* Read status - fast register access */
    status = readl(dev->regs + STATUS);
    
    if (!(status & MY_INTERRUPT_PENDING))
        return IRQ_NONE; /* Not our interrupt */
    
    /* Acknowledge immediately */
    writel(status, dev->regs + STATUS);
    
    /* Save status for bottom half */
    dev->pending_status = status;
    
    /* Schedule bottom half processing */
    if (status & DATA_READY)
        schedule_work(&dev->data_work);
    
    if (status & ERROR_FLAG)
        schedule_work(&dev->error_work);
    
    return IRQ_HANDLED;
}
 
/* Bottom Half - Runs in process context */
static void my_data_work_func(struct work_struct *work)
{
    struct my_device *dev = container_of(work, 
                                         struct my_device, 
                                         data_work);
    void *buffer;
    
    /* Now we can sleep for memory allocation */
    buffer = kmalloc(BUFFER_SIZE, GFP_KERNEL);
    if (!buffer) {
        dev_err(dev->dev, "Allocation failed
");
        return;
    }
    
    /* Perform actual data processing */
    mutex_lock(&dev->data_mutex);  /* Can sleep! */
    process_received_data(dev, buffer);
    mutex_unlock(&dev->data_mutex);
    
    /* Wake up waiting user processes */
    wake_up_interruptible(&dev->read_wait);
    
    kfree(buffer);
}

Context Violation = System Crash

Synchronization in Drivers

Sources of Concurrency:

SMP (Symmetric Multiprocessing): Multiple CPUs can execute driver code simultaneously
Preemption: The scheduler can preempt driver code to run other tasks
Interrupts: Hardware interrupts can occur at any time, even during critical sections
Kernel Threads: Work queues and other threads run independently
User Processes: Multiple processes may access the device concurrently

Synchronization Primitives in Drivers
Primitive	Use Case	Can Sleep?	Performance Impact
Spinlock	Short critical sections, interrupt context safe	No	Low for uncontended; high contention causes CPU spinning
Mutex	Long critical sections, only process context	Yes	Efficient for contended locks; lets CPU do other work
Semaphore	Limiting concurrent access count	Yes	Similar to mutex with configurable count
RW Lock (Reader-Writer)	Read-mostly data structures	Depends on variant	Allows concurrent readers; writers exclusive
RCU (Read-Copy-Update)	Read-frequently, write-rarely structures	Readers don't block	Optimal for read-heavy workloads; complex semantics
Atomic Operations	Simple counters and flags	No	Very low; hardware-level atomicity
Memory Barriers	Ordering memory operations	No	Required for lock-free algorithms

Choosing the Right Primitive:

Use spinlocks when:

The critical section is very short (microseconds)
The code may run in interrupt context
You're protecting simple data structures

Use mutexes when:

The critical section may be long or variable length
The code might need to sleep (memory allocation, I/O waits)
You're only ever in process context

Use RCU when:

Readers vastly outnumber writers
You can tolerate eventual consistency for readers
Maximum read performance is critical

Lock Ordering:

driver-synchronization.c
Common Synchronization Patterns
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
/* Pattern 1: Spinlock for hardware register access */
static void write_device_register(struct my_device *dev, 
                                   u32 reg, u32 value)
{
    unsigned long flags;
    
    spin_lock_irqsave(&dev->lock, flags);  /* Disable interrupts, take lock */
    writel(value, dev->regs + reg);
    spin_unlock_irqrestore(&dev->lock, flags);  /* Restore interrupts, release */
}
 
/* Pattern 2: Mutex for file operations */
static ssize_t mydev_read(struct file *file, char __user *buf,
                          size_t count, loff_t *ppos)
{
    struct my_device *dev = file->private_data;
    ssize_t ret;
    
    /* Can sleep - appropriate for process context */
    if (mutex_lock_interruptible(&dev->io_mutex))
        return -ERESTARTSYS;
    
    /* Perform I/O operation that may wait */
    ret = wait_event_interruptible(dev->wait_queue,
                                   has_data_available(dev));
    if (ret == 0)
        ret = copy_data_to_user(dev, buf, count);
    
    mutex_unlock(&dev->io_mutex);
    return ret;
}
 
/* Pattern 3: Protecting shared state between ISR and process context */
static void update_device_state(struct my_device *dev, u32 new_state)
{
    unsigned long flags;
    
    spin_lock_irqsave(&dev->state_lock, flags);
    dev->state = new_state;
    dev->state_changed = true;
    spin_unlock_irqrestore(&dev->state_lock, flags);
    
    /* Wake up anyone waiting on state change */
    wake_up_interruptible(&dev->state_wait);
}
 
static irqreturn_t mydev_isr(int irq, void *dev_id)
{
    struct my_device *dev = dev_id;
    u32 status;
    
    spin_lock(&dev->state_lock);  /* IRQ already disabled */
    status = readl(dev->regs + STATUS);
    if (status & STATE_CHANGED)
        dev->state_changed = true;
    spin_unlock(&dev->state_lock);
    
    return IRQ_HANDLED;
}

The Deadlock Danger

Summary: Driver Architecture

We've explored the foundational concepts of device driver architecture. Let's consolidate the key takeaways:

Key Takeaways

•Drivers bridge hardware and software — They translate abstract OS operations into device-specific commands and vice versa, enabling hardware abstraction.
•Layered architecture enables code reuse — From VFS through device drivers, each layer handles specific concerns, reducing duplication and simplifying development.
•Drivers consist of well-defined components — Initialization, operations structure, interrupt handlers, deferred processing, power management, and error handling.
•Subsystems provide frameworks — Block, character, network, and other subsystems reduce boilerplate and ensure consistent behavior across device classes.
•Registration and discovery match drivers to devices — ID tables and probe functions enable automatic device detection and configuration.
•Execution context determines valid operations — Interrupt context forbids sleeping; process context allows it. Violations cause crashes.
•Synchronization is mandatory — SMP, preemption, and interrupts create concurrency that must be handled with appropriate locking primitives.

What's Next:

Page Complete