AI guide
【One-Line Pitch】
A hands-on guide to writing Linux kernel device drivers from scratch, taking you from module basics through character devices, device tree, interrupts, and subsystem-specific drivers. Best for embedded engineers and systems programmers who know C and want to move from using drivers to authoring them.
【Book Arc】
- **Opening (~0%–12%)**: Sets up the kernel module model — how modules load and unload, how `__init`/`__exit` and ELF sections work, and how to build a first driver. Solves the "where does driver code even live and run" problem.
- **Early (~12%–30%)**: Core kernel facilities you reuse everywhere — logging with `printk`/`pr_*`, kernel data structures like lists, sleeping and timers, locking (mutex/spinlock), and deferred work via softirqs, tasklets, and workqueues.
- **Early–Middle (~30%–45%)**: Character device drivers end to end — allocating/registering a `cdev`, implementing `open`/`read`/`write`/`ioctl`, and handling user/kernel data movement with `copy_from_user` and friends.
- **Middle (~45%–60%)**: Platform devices and the device tree — matching drivers via `compatible`/`of_match_table`, pulling resources like IRQs from DT nodes, and wiring up interrupt handlers.
- **Late (~60%–85%)**: Subsystem-specific drivers — memory management, PWM, RTC, IIO, and IRQ management — showing how the same core patterns adapt to different kernel frameworks.
- **Ending (~85%–100%)**: Advanced topics — direct memory access (DMA) and network device drivers, rounding out the toolkit toward writing drivers from scratch.
【Key Takeaways】
- **Modules are the entry point to kernel code** (Opening): loading/unloading, `__init`/`__exit` section placement, and ELF section mechanics explain why driver code behaves differently from user-space programs.
- **The kernel is freestanding — no C library** (Early): you must use kernel-provided equivalents for strings, memory, sleeping, and timing, which shapes every design decision.
- **Deferred work has three flavors with distinct contexts** (Early): softirqs and tasklets run in atomic context, workqueues in process context; choosing wrong leads to subtle bugs.
- **Character devices follow a repeatable skeleton** (Middle): register a `cdev`, implement file operations, and carefully validate offsets and copy data across the user/kernel boundary.
- **Device tree drives modern platform driver matching** (Middle): the `compatible` string and `of_match_table` connect hardware descriptions to driver probe functions.
- **Interrupt handling splits into top and bottom halves** (Middle): threaded IRQs and `IRQF_ONESHOT` let you push heavy work out of the hard-IRQ path.
- **Subsystems reuse core patterns** (Late): PWM, RTC, IIO, and IRQ management each wrap the same fundamentals in framework-specific APIs.
- **DMA and networking are the advanced frontier** (Ending): these chapters extend the basics into performance-sensitive, high-throughput driver territory.
【Reading Tips】
- Deep-read the early chapters on module structure, locking, and deferred work — everything later depends on getting these right.
- Skim the subsystem chapters (PWM, RTC, IIO) on first pass, then return when you actually need a specific framework.
- Treat the character device and device tree chapters as your reference templates; they are the most reusable patterns in the book.
- Pay attention to context rules (atomic vs. process) around timers, workqueues, and IRQs — these are the most common source of driver bugs.
- Keep the kernel version in mind (v4.13); APIs may have shifted in newer kernels, so verify against current documentation.
【Coverage Limits】
This guide is based on stratified excerpts covering the book's opening through middle sections; the later subsystem, DMA, and networking chapters are summarized from the blurb and index rather than detailed excerpt content.
Passage locations
Excerpt 1
as follows: #include <linux/of.h> #include <linux/of_device.h> Any command-line input or output is written as follows: sudo apt-get update sudo apt-get insta...
View in text
Excerpt 2
into a buffer and the function will return, never blocking. The current console holder will then be notified about new messages and will print them before re...
View in text
Excerpt 3
linux/slab.h> /* for kmalloc() */ #include <linux/workqueue.h> //static DECLARE_WAIT_QUEUE_HEAD(my_wq); static int sleep = 0; struct work_data { struct work_...
View in text
Excerpt 4
efine EEP_GET_SIZE _IOR(EEP_MAGIC, GET_SIZE, int *) #endif Device provisioning - the old and depreciated way Device provisioning - the old and depreciated wa...
View in text