学习Linux设备驱动开发时大多数人遇到的第一道坎不是寄存器操作而是不知道一个最简单的驱动程序在系统里要经历哪些步骤源码如何编译、模块如何加载、设备节点如何创建、应用程序如何访问。这中间只要有一个环节没走通后面的中断、并发、设备树、平台驱动就全都建立在悬空基础上。《手把手教你学Linux设备驱动开发》已经正式出版这本书以字符设备驱动为起点把“编写驱动 - 编译模块 - 加载验证 - 用户程序访问”这条主线串得非常清楚适合准备进入嵌入式Linux方向、或者已经在做应用开发想向下探一层的开发者。本文不准备复制书里的目录而是围绕“字符设备驱动框架”这条主线搭建一个可以在虚拟机上直接运行的最小实验。你可以没有开发板只需要一台 Ubuntu 虚拟机、一套编译工具、一份匹配的内核头文件。读完并动手做完之后你会理解驱动模块在内核里的注册过程、设备节点和主设备号的关系、应用程序的 open/read/write 是如何通过 file_operations 进入内核的并且知道加载失败时该去哪看日志、按什么顺序排查。1. 学习Linux设备驱动前先把技术主线定下来1.1 设备驱动到底在解决什么问题先放下“驱动”这个词带来的神秘感。从一段运行在用户空间的应用程序视角来看访问一个设备通常就是打开文件、读写数据、关闭文件这三件事。硬件设备本身并不认识 open/read/write也不理解文件描述符它只认识寄存器、地址、中断和时序。设备驱动就是夹在中间的一层翻译程序。它向上通过 Linux 内核提供的接口注册成一种“可以被用户空间当文件操作”的对象向下通过读写寄存器、处理中断、维护数据缓冲让真实的硬件完成对应操作。理解这个分层关系比记住一堆内核 API 更重要。在没有硬件的情况下这个模型依然成立你可以把一段内核内存当成“虚拟设备”用户空间向它写入字符串再从它读出来驱动做的事情只是转发和暂存。这个最小模型跑通以后再去看 I2C、SPI、GPIO 这类真实外设驱动思路是完全一致的只是数据通路更长。1.2 为什么字符设备驱动是最合适的入门切入口Linux 设备通常分成三类字符设备、块设备、网络设备。它们对用户空间的呈现方式完全不同。设备类型用户空间访问方式数据特点典型代表字符设备/dev/xxx按字节流读写顺序访问不经过页缓存串口、GPIO、I2C、SPI、LED块设备/dev/xxx按块读写随机访问有页缓存和 IO 调度硬盘、U 盘、SD 卡网络设备通过 socket不直接访问/dev报文收发使用 sk_buff 管理网卡、无线网卡字符设备之所以适合学习是因为它把“用户态调用系统调用 - VFS 找到设备节点 - 通过 file_operations 进入驱动”这条链路压缩得非常短。你写的驱动只需要实现 open、read、write、release 这几个函数就能完成一次完整的数据交互。块设备引入页缓存、请求队列、IO 调度之后代码路径会复杂很多网络设备则要理解协议栈和 sk_buff 的内存管理对新手来说直接面对它很容易被细节淹没。日常嵌入式开发里遇到的大多数外设比如 LED、按键、传感器、屏幕、串口在 Linux 下都可以先用字符设备驱动去承载。1.3 新手常见的三个认知误区第一个误区是“没有开发板就学不了驱动”。实际上驱动编写的核心是理解框架而框架验证并不依赖特定硬件。字符设备驱动可以把一段内核内存作为操作对象加载到虚拟机上运行整个过程完全不涉及真实外设。等你理解了设备模型、注册过程、文件操作接口之后再放到开发板上做寄存器读写会轻松很多。第二个误区是“驱动开发等同于写汇编和寄存器”。Linux 驱动的主体是 C 代码程序逻辑绝大多数是对数据结构、链表、锁、回调函数的处理寄存器操作只出现在最底层的外设控制函数里。入门阶段甚至可以不碰寄存器。第三个误区是“拿到厂商驱动模板就能改改交差”。厂商提供的驱动是通用版本它需要适配你的内核版本、设备树、外设引脚和业务行为。如果只看模板而不理解平台驱动注册、设备树匹配、file_operations 的调用时机模板一换内核版本就失效出了问题也没有排查思路。2. 搭建学习环境不依赖开发板也能完成第一版驱动2.1 学习环境要求清单推荐的实验环境是一台 Ubuntu 虚拟机或者一台安装了普通发行版的旧电脑。不建议直接在 Windows 上强行编译内核模块因为内核模块与运行内核必须版本匹配跨系统编译的坑会掩盖掉驱动本身的逻辑问题。下面是一个可以直接对照准备的环境清单。项目建议配置说明操作系统Ubuntu 20.04 或 22.04 x86_64虚拟机或物理机均可内核版本与安装的内核头文件一致使用uname -r确认编译工具gcc、make安装build-essential即可内核头文件linux-headers-$(uname -r)编译模块时必须使用目标平台x86_64真实开发板可放到下一阶段辅助工具insmod、rmmod、lsmod、dmesg、mknod系统自带无需额外安装2.2 验证内核头文件和编译工具是否齐全先确认当前内核版本uname -r再检查对应的内核头文件目录是否存在ls -l /lib/modules/$(uname -r)/build ls -l /lib/modules/$(uname -r)/build/Makefile如果目录不存在说明没有安装内核头文件。Ubuntu 系统可以直接安装sudo apt update sudo apt install build-essential linux-headers-$(uname -r)这里要注意内核模块编译并不需要完整下载一份 Linux 内核源码。头文件包会生成/lib/modules/$(uname -r)/build这个符号链接指向一批编译模块所需的 Makefile、Kconfig 和头文件。make工具进入这个目录后会找到当前内核的编译规则用它来生成与运行内核匹配的.ko文件。检查编译器gcc --version make --version如果输出版本信息环境就基本就绪了。2.3 学习环境与生产环境的差异虚拟机上能跑通不代表生产环境可以照搬。内核模块是运行在内核态的代码加载错误可能导致系统不稳定、内核崩溃甚至无法启动。学习环境主要用来打通流程生产环境还需要考虑更多约束。维度学习环境生产环境内核版本与当前虚拟环境一致即可需要指定兼容范围常需多版本适配模块签名一般不开启强制校验可能要求内核模块签名配合 UEFI Secure Boot加载方式手动insmod/rmmod测试需要配置开机自动加载、依赖顺序、参数校验调试手段printkdmesg足够需要结合 ftrace、tracepoint、内核日志系统、远程日志异常影响大不了重启虚拟机可能导致业务中断需要回滚和灰度加载策略设备节点手动mknod测试需要通过设备模型自动创建借助 udev 或 devtmpfs注意在物理机或生产服务器上测试未经验证的内核模块时必须确认模块来源、内核版本匹配和已执行回滚方案。虚拟机的容错成本要低很多。3. 编写并编译一个最小字符设备驱动3.1 项目结构和目标在用户目录下建立实验目录mkdir ~/hello_drv cd ~/hello_drv实验目录里只需要三个文件。hello_drv.c是驱动源码Makefile告诉内核构建系统如何编译它test_app.c是用户态测试程序用来验证驱动是否真的工作。~/hello_drv/ ├── hello_drv.c ├── Makefile └── test_app.c这个实验的目标很清晰驱动加载后在/dev下创建一个设备节点向它写入字符串再读回来。整个过程不涉及真实硬件但完整覆盖了字符设备驱动的注册、数据传输和释放链路。3.2 驱动源码从 module_init 到 file_operations创建hello_drv.c写入完整的最小字符设备驱动#include linux/init.h #include linux/module.h #include linux/fs.h #include linux/uaccess.h #include linux/string.h #define DEVICE_NAME hello_drv static int major; static char kernel_buffer[128] hello from kernel\n; static int open_count; static int hello_open(struct inode *inode, struct file *filep) { open_count; pr_info(hello_drv: open, open_count%d\n, open_count); return 0; } static ssize_t hello_read(struct file *filep, char __user *buffer, size_t len, loff_t *offset) { size_t msg_len strlen(kernel_buffer); if (*offset msg_len) return 0; if (len msg_len - *offset) len msg_len - *offset; if (copy_to_user(buffer, kernel_buffer *offset, len)) return -EFAULT; *offset len; return len; } static ssize_t hello_write(struct file *filep, const char __user *buffer, size_t len, loff_t *offset) { if (len sizeof(kernel_buffer)) len sizeof(kernel_buffer) - 1; if (copy_from_user(kernel_buffer, buffer, len)) return -EFAULT; kernel_buffer[len] \0; pr_info(hello_drv: write %zu bytes\n, len); return len; } static int hello_release(struct inode *inode, struct file *filep) { pr_info(hello_drv: close\n); return 0; } static struct file_operations hello_fops { .owner THIS_MODULE, .open hello_open, .read hello_read, .write hello_write, .release hello_release, }; static int __init hello_init(void) { major register_chrdev(0, DEVICE_NAME, hello_fops); if (major 0) { pr_alert(hello_drv: register_chrdev failed\n); return major; } pr_info(hello_drv: registered, major%d\n, major); return 0; } static void __exit hello_exit(void) { unregister_chrdev(major, DEVICE_NAME); pr_info(hello_drv: unregistered\n); } module_init(hello_init); module_exit(hello_exit); MODULE_LICENSE(GPL); MODULE_AUTHOR(Your Name); MODULE_DESCRIPTION(A minimal character device driver); MODULE_VERSION(0.1);这段代码虽然短但已经包含了字符设备驱动的核心要素module_init(hello_init)告诉内核加载模块时调用hello_init。register_chrdev(0, DEVICE_NAME, hello_fops)注册一个字符设备第一个参数传 0 表示让内核自动分配主设备号。file_operations结构体把应用层的 open、read、write、close 系统调用映射到驱动函数。copy_to_user和copy_from_user负责内核空间与用户空间的数据拷贝不能直接用memcpy。MODULE_LICENSE(GPL)是必填项缺失会导致加载时提示“module license unspecified taints kernel”。3.3 Makefile让内核构建系统编译模块再创建Makefileobj-m : hello_drv.o KDIR : /lib/modules/$(shell uname -r)/build PWD : $(shell pwd) all: make -C $(KDIR) M$(PWD) modules clean: make -C $(KDIR) M$(PWD) clean关键行是obj-m : hello_drv.o。它的含义是把hello_drv.c编译成一个内核模块目标文件是hello_drv.ko。KDIR指向的是上一节验证过的内核头文件目录M$(PWD)告诉make在当前目录查找源文件并输出编译结果。不要自己用gcc -c直接编译这个.c文件。内核模块必须使用内核的构建系统因为它需要获取内核编译时生成的头文件、宏定义和 ABI 信息不同内核版本的编译规则也不同。3.4 编译并确认产物在~/hello_drv目录下执行make编译成功后目录下会多出hello_drv.ko文件。用file命令确认模块格式ls -l hello_drv.ko file hello_drv.ko modinfo hello_drv.komodinfo会输出模块描述、作者、许可证和版本号这些来自源码末尾的MODULE_*宏。注意不要在生产服务器或无法接受重启风险的机器上反复编译加载未知模块。实验阶段建议在虚拟机里完成。4. 加载、验证与卸载的完整闭环4.1 加载模块并确认内核日志加载模块需要 root 权限sudo insmod hello_drv.ko加载后先看内核日志dmesg | tail -n 10预期能看到两行关键日志一行是hello_drv: registered, majorxxx另一行是来自hello_init的hello_drv: registered。majorxxx是内核自动分配的主设备号这个数字在后面创建/dev节点时要用。再确认模块确实加载到了内核lsmod | grep hello_drvinsmod适合加载单一模块文件。如果模块之间有依赖比如一个模块调用了另一个导出的符号应该使用modprobe它会根据依赖关系自动加载并处理模块路径。4.2 创建设备节点驱动注册了字符设备内核里有设备号但用户空间还看不到它。需要手动在/dev下创建设备节点cat /proc/devices | grep hello_drv输出类似240 hello_drv其中第一列是主设备号。使用这个号码创建设备节点sudo mknod /dev/hello_drv c 240 0 sudo chmod 666 /dev/hello_drvmknod的参数含义是c表示字符设备240是主设备号0是次设备号。在这个最小例子里只有一个设备实例次设备号填 0 即可。chmod 666是为了让普通用户不需要sudo也能打开设备文件方便实验生产环境不应该这样配置权限。检查节点ls -l /dev/hello_drv如果看到crw-rw-rw- 1 root root 240, 0 ... /dev/hello_drv说明设备节点已经和字符设备号绑定。4.3 用应用程序验证读写流程创建test_app.c#include stdio.h #include fcntl.h #include unistd.h #include string.h int main(void) { int fd; char buf[128]; ssize_t n; fd open(/dev/hello_drv, O_RDWR); if (fd 0) { perror(open); return 1; } write(fd, hello from user, 15); lseek(fd, 0, SEEK_SET); memset(buf, 0, sizeof(buf)); n read(fd, buf, sizeof(buf) - 1); if (n 0) { printf(read %zd bytes: %s\n, n, buf); } close(fd); return 0; }编译并运行gcc -o test_app test_app.c ./test_app预期输出read 15 bytes: hello from user这个结果说明用户程序写入的字符串已经通过hello_write进入了驱动维护的kernel_buffer再通过hello_read读回用户空间。再看一次内核日志dmesg | tail -n 10能看到hello_drv: open、hello_drv: write 15 bytes、hello_drv: close三条日志。4.4 卸载模块和清理设备节点实验结束后先删除设备节点再卸载模块sudo rm -f /dev/hello_drv sudo rmmod hello_drv查看模块是否已经卸载lsmod | grep hello_drv dmesg | tail -n 5dmesg中出现hello_drv: unregistered说明hello_exit被正确调用unregister_chrdev已经释放了设备号。如果设备节点删除顺序弄反了只要模块还处于加载状态设备节点就仍然有效。比较安全的习惯是先删/dev节点再卸载模块避免出现“节点存在但对应的内核处理函数已经不存在”的尴尬状态。5. 关键机制详解为什么这个框架能跑起来5.1 module_init 与 module_exit 的注册时机驱动源码里并没有 C 语言意义上的main函数。module_init和module_exit是内核模块的两个生命周期入口。当执行insmod hello_drv.ko时内核加载模块文件然后调用hello_drv模块的 init 函数也就是hello_init。在这个函数里程序通过register_chrdev注册设备号并把自己的file_operations交给内核。当执行rmmod hello_drv时内核调用 exit 函数也就是hello_exit在这里释放设备号。这两个函数的命名可以任意关键是注册方式。module_init(hello_init)不叫“定义函数”而叫“告诉内核入口在哪”。这也是为什么一个模块只需要一个入口和一个出口的原因内核需要知道何时执行初始化、何时执行清理。5.2 file_operations 与系统调用的对应关系file_operations是用户空间行为进入内核的第一个门面。当test_app.c调用open(/dev/hello_drv, O_RDWR)时VFS 层根据设备节点中的设备号找到驱动然后查找hello_fops里有没有.open回调。有就调用它。对应关系可以整理成一张表。用户空间代码系统调用驱动回调本示例函数fd open(...)sys_open.openhello_openread(fd, buf, len)sys_read.readhello_readwrite(fd, buf, len)sys_write.writehello_writeclose(fd)sys_close.releasehello_release这里要特别理解.release和.close的区别。close(fd)只是减少了文件描述符的引用计数只有当最后一个引用被释放时内核才会调用.release。对初学者来说大部分简单驱动可以认为 “close 最终会触发 release但中间可能隔一个计数过程”。5.3 动态主设备号与静态主设备号的选择register_chrdev(0, DEVICE_NAME, hello_fops)的第一个参数是请求的主设备号。传 0 表示动态分配内核会在空闲设备号里挑一个给这个驱动。这种方式适合教学和个人实验因为你不需要去查哪些主设备号被占用。如果设备号冲突register_chrdev会返回负值hello_init会把这个负值直接返回给内核模块加载失败。生产环境推荐使用 Linux 设备模型中的alloc_chrdev_regioncdev_add组合它比register_chrdev更灵活也方便自动创建设备节点。可以把它理解成一个老式入口和一个现代入口的区别老式入口代码简单现代入口更符合内核当前推荐的写法。5.4 printk 与日志级别的调试方式示例中使用的是pr_info它等价于printk(KERN_INFO ...)。内核日志按级别从高到低分为KERN_EMERG、KERN_ALERT、KERN_CRIT、KERN_ERR、KERN_WARNING、KERN_NOTICE、KERN_INFO、KERN_DEBUG。使用dmesg查看日志时能看到的级别取决于当前内核日志级别配置。默认配置会显示KERN_INFO及以上级别。如果哪天发现自己的调试日志不显示可以先检查是不是用了KERN_DEBUG再确认内核日志级别。在学习阶段pr_info足够直观。生产环境不宜大量使用printk因为它会往内核日志缓冲区写数据调用频繁的路径会造成额外开销。更合适的做法是使用动态调试dynamic_debug或ftrace让日志按需开关。6. 常见问题和排查路径6.1 编译时报错找不到 build 目录现象make -C /lib/modules/5.15.0-xxx-generic/build M/home/user/hello_drv modules /bin/sh: 1: cd: cant cd to /lib/modules/5.15.0-xxx-generic/build原因是对应内核版本的内核头文件没有安装或者升级内核后没有重启。检查方式uname -r ls -l /lib/modules/$(uname -r)/build解决方式安装匹配版本的头文件包sudo apt install linux-headers-$(uname -r)6.2 insmod 提示 Operation not permitted现象insmod: ERROR: could not insert module hello_drv.ko: Operation not permitted常见原因有三个模块许可证缺失导致内核拒绝加载、当前系统开启了 Secure Boot、模块版本与当前内核不匹配。先执行modinfo hello_drv.ko看许可证。如果没有license:字段说明源码里没有MODULE_LICENSE需要补上MODULE_LICENSE(GPL)后重新编译。如果是 Secure Boot 环境系统会拒绝对未签名内核模块的加载。学习环境可以在虚拟机关闭 Secure Boot也可以在 BIOS 里关闭生产环境应该走正式的内核模块签名流程。6.3 mknod 后打开设备节点报 No such device现象./test_app open: No such device原因通常是主设备号填错或者设备节点创建时使用的设备号与模块实际注册的号码不一致。检查方式cat /proc/devices | grep hello_drv ls -l /dev/hello_drv确认/proc/devices里输出的主设备号和ls -l /dev/hello_drv中逗号前的数字一致。不一致就删掉节点重建。6.4 加载成功但 read 返回错误或没有数据现象程序 open 成功了但read返回-1perror显示Bad address。原因基本指向copy_to_user失败。在驱动函数里如果传入的用户空间地址无效比如缓冲区不可写copy_to_user会返回非零值此时驱动返回-EFAULT应用程序就会收到Bad address。检查方式确认应用层传给read的buf指针是真的指向一段有效内存确认设备节点本身没有被误用为只读模式。如果驱动实现里使用了kern_buffer这类静态缓冲需要判断它到底应该来自kmalloc还是全局变量避免生命周期问题。6.5 卸载提示 Module is in use现象sudo rmmod hello_drv rmmod: ERROR: Module hello_drv is in use原因是用户空间的某个进程仍然持有该设备节点对应的文件描述符模块引用的文件对象没有被释放。检查方式lsof | grep hello_drv ps -ef | grep test_app处理方式结束占用设备节点的进程sudo pkill test_app然后再次卸载模块。如果仍然提示占用可能驱动内部自己增加过引用计数但一直没有释放这种内部引用泄漏在简单字符设备驱动里很少发生但如果出现了要检查是否有其他模块引用了这个驱动导出的符号。把常见问题汇总成一张表方便后续直接查。问题现象常见原因检查方式处理建议编译找不到 build 目录内核头文件未安装ls /lib/modules/$(uname -r)/build安装linux-headers-$(uname -r)insmod 权限拒绝Secure Boot / 许可证缺失modinfo hello_drv.ko补MODULE_LICENSE按安全策略处理签名/dev设备节点打不开主设备号填错 / 节点未创建cat /proc/devices对比ls -l /dev/hello_drv删除节点用正确设备号重建read 返回 Bad addresscopy_to_user失败检查用户缓冲区有效性修正应用层缓冲区或驱动判断逻辑rmmod 提示模块占用进程仍持有设备节点lsof/ps -ef结束占用进程后重新卸载7. 从最小框架走向生产级驱动7.1 下一步应该学的五个方向最小字符设备驱动跑通只代表你理解了驱动的基本框架。后面真正进入嵌入式 Linux 项目时还需要逐个攻破这些方向第一是并发与竞态。多个进程同时 open 同一个设备节点时open_count的递增就不是安全的读写操作里如果没有锁数据可能被另一进程破坏。需要学习自旋锁、互斥锁、原子变量、读写锁各自的适用场景。第二是设备模型。从register_chrdev换成devtmpfs自动创建设备节点需要理解class_create、device_create、cdev_add这些更现代的接口。第三是设备树。开发板上的外设地址、中断号、引脚复用都写在设备树节点里平台驱动需要解析设备树并获取硬件资源。这个阶段开始接触真实的寄存器读写。第四是中断与延时。等待硬件事件时不能忙等需要用等待队列、完成量、tasklet、workqueue 或 threaded irq 把上下文切换的代价控制住。第五是内核调试工具。printk只是最基础的手段后续应该熟悉 ftrace、kprobe、perf、动态调试、dump_stack 等工具用来定位内核崩溃、死锁和高延迟问题。7.2 生产环境代码比示例多考虑什么当前位置的示例代码只用到了全局缓冲区不涉及内存申请、硬件映射和并发保护。生产驱动要从几个方面补齐内存方面要用kmalloc、kzalloc、devm_kzalloc申请内核内存并记得在exit或remove中释放。使用设备管理接口devm_系列可以在驱动解绑时自动释放资源减少泄漏风险。权限方面字符设备节点的读写权限必须按应用场景设置不要一律chmod 666。设备文件只对需要的用户组可读写配合 udev 规则管理节点权限。调试方面生产环境不能频繁使用printk。可以用dev_dbg、trace_printk或 dynamic_debug让日志开关可在运行时切换。兼容方面不同内核版本之间API 可能变化。比如旧版使用的create_proc_entry后来换成proc_create某些函数从EXPORT_SYMBOL变为EXPORT_SYMBOL_GPL。在项目里维护一套内核版本兼容层或者用LINUX_VERSION_CODE做条件编译都是常见做法。7.3 结合《手把手教你学Linux设备驱动开发》的学习路径针对已经具备 C 语言基础但第一次接触内核模块开发的读者推荐的学习顺序是第一步把本文的实验完整做三遍。第一遍直接复制代码跑通第二遍不看代码自己重写第三遍尝试修改行为比如把缓冲区改成双向循环、限制最大写入长度、增加多个设备次设备号。第二步阅读《手把手教你学Linux设备驱动开发》中字符设备驱动、并发控制、中断处理、平台驱动这几章用书里的更完整案例补齐自己的实验。看书时不要只盯着代码重点看作者对“为什么这样设计”的解释。第三步准备一块常见的开发板把字符设备驱动迁移到真实硬件上。例如点亮一颗 LED设备树里描述引脚、平台驱动解析寄存器地址、通过读写 GPIO 寄存器控制引脚电平。从这一步开始驱动才真正和硬件打交道。第四步回到内核文档。Documentation/driver-api和内核源码的samples目录里有大量官方示例比任何博客都值得反复阅读。遇到 API 变化时以当前系统内核源码为准。注意学习驱动的过程不是线性看书的单一过程正确做法是“框架理论 - 最小实验 - 硬件实验 - 回到源码验证理论”这样循环推进。7.4 可复用的驱动开发检查清单每次完成一个驱动模块后可以按下面的清单做一次自查。[ ] 内核版本和头文件版本是否一致是否用uname -r确认过。[ ] 源码中是否包含MODULE_LICENSE避免触发内核 taint 标记。[ ]file_operations中每个回调是否处理了空指针和非法参数。[ ] 用户态数据拷贝是否使用copy_to_user/copy_from_user而不是直接memcpy。[ ] 打开和关闭路径是否对称init失败后是否清理了已注册的资源。[ ] 设备节点是否能通过设备模型自动创建而不是依赖手动mknod。[ ] 并发访问路径是否加锁写缓冲区是否可能被多进程同时修改。[ ] 卸载模块前是否清理了/dev节点和内核线程。[ ] 日志级别是否合理生产环境里是否保留了高频printk。[ ] 是否有回滚方案模块加载后系统能否在异常时恢复到上一个状态。把这套清单沉淀下来后续写 I2C、SPI、串口、GPIO 驱动时可以直接复用。真正走上嵌入式 Linux 开发以后你会发现最值钱的不是记得住某个 API而是能快速定位“框架哪里断了、数据在哪一层丢的、日志该去哪看”的能力。最小字符设备驱动练习就是为了建立这种感觉。