写在内核驱动系列的第4篇我特意把字符设备驱动单独拎出来讲。不是因为字符设备比块设备、网络设备更高级恰恰相反字符设备是Linux驱动里最简单、最基础的一类设备但几乎所有入门内核驱动的第一课都从它开始。简单意味着结构清晰你能在最短时间内走通“设备注册–文件操作–数据交互–用户态验证”这条完整链路后面的复杂机制无非是在这条链路上加缓冲、加并发控制、加异步通知。这篇文章我会绕开教科书式的罗列用一个真实可跑的字符设备驱动样例把框架、数据结构、代码细节和踩坑点一次讲透。适合谁来读刚接触Linux驱动开发的人以及把驱动框架背得滚瓜烂熟但一写代码就出各种怪问题的同学。我会尽量把每个API背后的设计意图讲明白而不是让你死记函数原型。内核版本以长期维护版本为主代码在老版本上基本也能编译通过差异我会顺带标注。1. 整体设计为什么字符设备驱动是内核编程的“敲门砖”1.1 先搞清楚字符设备和其他设备的边界字符设备是数据按字节流顺序访问的设备典型代表是串口、鼠标、声卡这类交互型硬件。它的特点是没有缓冲区读写数据时是一个字节一个字节地顺序处理设备本身不管理数据的固定块结构。比如你往串口发一帧数据内核不会帮你攒够某个数量再一次性交出去而是你写一个字节它就转发一个字节这也决定了字符设备的file_operations接口天然适合逐字符、逐个请求的处理逻辑。块设备则完全不同。硬盘、SD卡这类设备以固定大小的块为单位读写内核在中间还有一整套页缓存、IO调度机制驱动开发的核心工作其实是配合通用块层而不是直接暴露所有细节。网络设备就更特殊它面向数据包的收发不走设备节点不通过文件系统暴露用socket接口交互。从驱动架构复杂度来说网络设备最高块设备次之字符设备最低。所以入门必须从字符设备开始。内核里一切硬件最终都要面向用户态提供某种操作入口字符设备这个入口的形态最直观——用户态打开一个设备文件read就是读设备write就是写设备ioctl就是控制硬件。你不需要理解复杂的调度和缓冲机制就能建立“设备文件–驱动–硬件”这条完整认知。1.2 选择“内核模块”还是“内建驱动”写字符设备驱动第一件事不是敲代码而是决定驱动以什么形式进入内核。有两条路把代码放到内核源码树里编成内建驱动或者编成独立的可加载内核模块。对于学习和前期调试模块几乎是唯一合理的选择。模块的好处是你可以独立编译、独立加载、独立卸载整个开发循环是“改代码 → 编译 → 加载 → 测试 → 卸载”不需要反复重启系统。内建驱动一旦编进内核镜像任何改动都得重新编译内核再重启验证效率极低。生产环境的设备驱动前期开发也基本都是先做模块验证稳定后再考虑内建。加载和卸载模块的命令也很简单但有几个细节必须养成习惯sudo insmod my_driver.ko sudo rmmod my_driver lsmod | grep my_driver dmesg | tailinsmod是“install module”的缩写加载指定路径下的模块文件。我见过不少人图省事直接用insmod不带路径前缀结果报找不到文件确认一下模块文件所在目录就行。加载后立刻dmesg看内核日志模块里打印的信息会出现在这里效率最高的调试方式永远是看日志而不是猜。1.3 一条完整链路先过一遍字符设备驱动从模块加载到用户态能访问中间至少经过四个环节分配设备号。设备号是驱动在内核里的身份证用户态看到的设备文件其实是设备号的映射。注册字符设备。告诉内核“这个设备号对应的操作函数是哪些”本质是把设备号和file_operations结构体关联起来。创建设备节点。设备节点在/dev目录下是用户态操作的入口文件。实现文件操作函数。用户态open、read、write等调用最终都会走到这里。这四步对应到代码实现分别会用到alloc_chrdev_region、cdev_add、device_create以及一个必须自己实现的file_operations结构体。后面我会逐个拆开讲先有个全局印象能帮你避免在某个细节里越陷越深。2. 核心基础设施设备号、cdev与file_operations2.1 设备号怎么分配、怎么用好主次设备号每个字符设备和块设备在内核里都靠设备号区分。设备号由主设备号major和次设备号minor组成各占12位和20位。主设备号标识设备对应的驱动次设备号标记同一驱动下管理的不同设备实例。比如你的驱动要同时支持两个虚拟串口主设备号相同次设备号分别为0和1用户态看到的设备文件就是不同的名字。分配设备号有两种方式。第一种是静态指定调用register_chrdev_region你得自己挑一个尚未占用的主设备号。这种方式在个人学习时没问题但一旦进入社区或者产品开发我没见过谁还在用静态分配因为不同驱动之间的设备号冲突极其恶心调试起来毫无头绪。第二种是动态分配调用alloc_chrdev_region该函数会自动帮你挑一个空闲的主设备号开发时更推荐这种方式。dev_t dev_num; int ret; ret alloc_chrdev_region(dev_num, 0, 1, my_driver); if (ret 0) { pr_err(alloc_chrdev_region failed: %d\n, ret); return ret; } pr_info(major %d, minor %d\n, MAJOR(dev_num), MINOR(dev_num));这段代码调用后内核会返回给你一个未使用的设备号主设备号从高位往下自动分配。MAJOR和MINOR是两个宏从dev_t类型里分别取出主、次设备号供打印或后续使用。注意第三个参数是次设备号数量如果这一驱动接下来要控制多个硬件这里就要分配足够的数量别等到注册时才发现不够。2.2 cdev结构体驱动和内核之间的“注册卡”拿到设备号只是第一步真正让内核知道你提供哪些文件操作要靠cdev结构体。你可以把它理解成一张注册卡上面写清楚“这个设备对应的函数集是谁”。初始化有两种风格老内核喜欢cdev_init和cdev_alloc分开用新内核则建议统一用cdev_initstruct cdev mycdev; cdev_init(mycdev, my_fops); mycdev.owner THIS_MODULE; ret cdev_add(mycdev, dev_num, 1); if (ret 0) { pr_err(cdev_add failed: %d\n, ret); unregister_chrdev_region(dev_num, 1); return ret; }cdev_add执行后驱动才算真正进入了内核的设备管理链表。这里必须检查返回值常见错误是设备号已经被别的驱动占用导致cdev_add返回-1。千万不要跳过这个检查直接往下走否则后续操作全部建立在一个没注册成功的设备上出错时会让你怀疑人生。owner字段设置为THIS_MODULE表示持有该模块的引用防止驱动被卸载时还有进程在操作这是保护机制。2.3 file_operations用户态的每个系统调用如何映射到驱动file_operations是字符设备驱动里最重要的结构体用户态对设备文件的所有操作最终都会转化为对这里函数指针的调用。它不是每个字段都必须实现你只实现需要的函数未实现的字段置空即可用户态调用对应操作时会返回-EINVAL。static const struct file_operations my_fops { .owner THIS_MODULE, .open my_open, .release my_release, .read my_read, .write my_write, .unlocked_ioctl my_ioctl, };这里最容易被误解的地方是open和release。很多人以为open是“打开硬件”的动作其实不然。open的默认内核行为是递增模块引用计数并创建文件结构真正的设备初始化动作是你自己在open回调里做的。release也不一定代表设备断电或断开只是最后一个引用被关闭时的清理机会。驱动里的open/release和“通电”“断电”没有必然关系。.owner THIS_MODULE是标准写法别漏漏了会出现驱动还在被打开状态就能被rmmod的诡异情况实际后果是用户态进程访问时模块已经没了产生oops。2.4 缓存和内存屏障被很多人忽略的那一栏普通驱动的file_operations里有几个函数你可能觉得用不到但越到后期越绕不开。llseek用于调整文件位置指针read/write必然会用到当前位置。fsync用于把缓存数据落盘对字符设备来说一般不需要实现。这些字段在处理高速设备或者需要严格时序控制的场景里特别重要我在做某个数据采集驱动时spi接口的设备就频繁用到llseek跳转缓冲区位置没实现的话用户态只能读取最开始的数据后面的数据全部错位。3. 动手写驱动一个可运行的字符设备驱动全解析3.1 模块框架与头文件写驱动外加用户态测试程序直接从模块框架开始。必要的头文件包括init.h模块生命周期、fs.h文件操作、cdev.h字符设备接口、uaccess.h用户态数据拷贝。#include linux/init.h #include linux/module.h #include linux/fs.h #include linux/cdev.h #include linux/uaccess.h #include linux/slab.h #define DEVICE_NAME chardev_demo #define BUF_SIZE 4096 static int major; static struct cdev demo_cdev; static char *kernel_buf;这里的kernel_buf是驱动内部用来存放数据的缓冲区。#define DEVICE_NAME chardev_demo用于模块参数和后续设备名称字符串会被内核沿用作为设备节点名的一部分。缓冲区大小不要拍脑袋定我自己最开始写了个几十字节的buf结果测试程序一次写入超过缓冲区大小copy_from_user直接越界整个系统直接宕机以后养成凡涉及缓冲区先考虑边界条件的习惯。3.2 初始化函数模块入口都干了哪些活模块的入口函数必须用__init标记对应的退出函数用__exit。这两个宏的核心作用是当驱动被编译进内核且不是模块时module_exit函数会被直接丢弃以节省内存。虽然对学习阶段影响不大但这是内核开发者的一个通用习惯。static int __init demo_init(void) { dev_t dev_num; int ret; ret alloc_chrdev_region(dev_num, 0, 1, DEVICE_NAME); if (ret 0) { pr_err(Failed to allocate device number\n); return ret; } major MAJOR(dev_num); kernel_buf kzalloc(BUF_SIZE, GFP_KERNEL); if (!kernel_buf) { unregister_chrdev_region(dev_num, 1); return -ENOMEM; } cdev_init(demo_cdev, demo_fops); demo_cdev.owner THIS_MODULE; ret cdev_add(demo_cdev, dev_num, 1); if (ret 0) { kfree(kernel_buf); unregister_chrdev_region(dev_num, 1); return ret; } pr_info(Demo driver loaded, major %d\n, major); return 0; }这段初始化函数体现了驱动开发的完整逻辑链先获取资源设备号、内存然后注册设备一旦中间任何一步失败必须把前面已经拿到的资源全部释放再返回。这里最容易犯的错误是失败路径不完全比如cdev_add失败后忘了unregister_chrdev_region结果设备号被白白占用后续加载同样的驱动永远提示资源被占。写驱动代码时每一个错误分支都要倒着往前释放资源这个习惯越早养成越好。GFP_KERNEL标志表示kernel_buf的分配是在进程上下文进行的如果中断上下文里用这个标志会睡眠从而引发调度器警告这是内核编程初学者最常踩的问题之一。中断上下文只能使用GFP_ATOMIC分配内存而且不能睡眠。3.3 文件操作核心实现open、release、read、writeopen的实现可以非常简练。在完整项目里会做权限检查、设备忙判断、资源预分配但在基础驱动里它的最小职责是确保设备“可用”。static int demo_open(struct inode *inode, struct file *filp) { pr_info(Device opened\n); return 0; }read和write是数据交互的核心也是最容易写错的部分。用户态的read调用到达驱动层时内核已经把用户空间缓冲区传入你需要把当前驱动的数据复制到用户态buf中然后返回读取的字节数。static ssize_t demo_read(struct file *filp, char __user *buf, size_t count, loff_t *ppos) { size_t bytes_to_read; if (*ppos BUF_SIZE) return 0; bytes_to_read min(count, BUF_SIZE - (size_t)*ppos); if (copy_to_user(buf, kernel_buf *ppos, bytes_to_read)) return -EFAULT; *ppos bytes_to_read; return bytes_to_read; }注意copy_to_user的返回值成功拷贝时返回0失败返回未能拷贝的字节数。返回值非0才是错误很多人习惯性写成if (copy_to_user(...) 0)判断成功逻辑上没错但容易让人误解在驱动里判断返回值总和“没拷贝成功”挂钩更清晰。同时看到__user标记了吗这是内核里非常重要的内存安全机制它只是一种编译器约定提醒你buf指向的是用户空间不能直接解引用必须用copy_to_user这类专用接口。write的逻辑正好反着来用户空间数据先拷贝进内核缓冲区然后存下来static ssize_t demo_write(struct file *filp, const char __user *buf, size_t count, loff_t *ppos) { size_t bytes_to_write; if (count BUF_SIZE) return -EINVAL; bytes_to_write min(count, BUF_SIZE - (size_t)*ppos); if (copy_from_user(kernel_buf *ppos, buf, bytes_to_write)) return -EFAULT; *ppos bytes_to_write; return bytes_to_write; }这里写了if (count BUF_SIZE) return -EINVAL;这是防御性的明显例子。如果用户一次写入超过缓冲区大小你还有后面的min保护但返回-EINVAL能让用户态程序及早知道问题而不是莫名被截断。我在实际项目里就遇到过类似情况用户态脚本写了个大文件进去结果数据不全排查半天才发现是缓冲区被截断了早加这个判断能省太多时间。release函数不需要额外处理时直接返回0static int demo_release(struct inode *inode, struct file *filp) { pr_info(Device released\n); return 0; }3.4 模块出口卸载时别留垃圾模块退出函数要把所有资源按逆序释放static void __exit demo_exit(void) { cdev_del(demo_cdev); kfree(kernel_buf); unregister_chrdev_region(MKDEV(major, 0), 1); pr_info(Demo driver unloaded\n); } module_init(demo_init); module_exit(demo_exit); MODULE_LICENSE(GPL);cdev_del把设备从内核移除然后释放内存最后归还设备号。MKDEV(major, 0)把主次设备号重新包装成dev_t类型配合前面分配的数量做释放。如果你在init时alloc了多个次设备号卸载时也要对应释放同样数量否则设备号泄漏内核设备号资源会被不断消耗。MODULE_LICENSE(GPL)不是可选项。没有它内核会认为你使用了非GPL许可证打印“kernel tainted”警告部分GPL-only的内核API也会被禁用。写开源驱动或学习用的是这个就行。4. 设备节点的创建与用户态测试程序4.1 手动创建节点还是自动创建设备节点就是/dev/xxx文件内核本身不会自动为字符设备创建节点需要额外机制。手动方式是一条mknod命令mknod /dev/chardev_demo c 248 0248是实际分配的主设备号0是次设备号。这种方式一次可行但每次重新加载驱动设备号都动态变化你都得先看dmesg再改mknod参数极其繁琐。更优雅的方式是改用class_create和device_create函数让驱动在加载时通过内核的devtmpfs机制自动生成设备节点static struct class *demo_class; demo_class class_create(DEVICE_NAME); if (IS_ERR(demo_class)) { ret PTR_ERR(demo_class); goto fail_class; } device_create(demo_class, NULL, dev_num, NULL, DEVICE_NAME);在现代内核环境里需要这个分支基本都能自动生成/dev节点。但注意这里的两个库函数已经对THIS_MODULE自动处理你不需要再手动设置owner。原来需要手动实现的device_create逻辑里dev_t参数把设备号和设备节点关联起来。使用这个机制之后/dev/chardev_demo节点会自动出现在de目录中。4.2 测试程序的设计思路与完整代码驱动写完用简单cat和echo或许能粗测但我会用一个正式的测试程序。因为我们需要验证read/write是否真的工作了位置指针ppos的行为是否符合预期以及掩码处理是否完整。#include stdio.h #include stdlib.h #include string.h #include fcntl.h #include unistd.h int main(void) { int fd; char buf[128]; ssize_t n; fd open(/dev/chardev_demo, O_RDWR); if (fd 0) { perror(open); return 1; } write(fd, hello from userspace, 20); lseek(fd, 0, SEEK_SET); n read(fd, buf, sizeof(buf)); if (n 0) { perror(read); close(fd); return 1; } buf[n] \0; printf(read %zd bytes: %s\n, n, buf); close(fd); return 0; }这段程序里有个非常关键的细节write之后为什么要lseek回0再read因为驱动里的ppos位置在write之后已经停留在写入结尾处如果不把pos重置到0read会从上次写入后的位置开始读结果读到0字节。这正是驱动层位置指针行为和用户态文件操作一致性的一个体现很多初学者被这个“写入后读不到数据”的坑困住过。编译测试程序用普通gcc即可不涉及内核头文件。测试驱动跑起来后dmesg里会依次出现加载日志、open日志、release日志、卸载日志。这四条日志缺哪一条都说明对应回调没有正确执行可以按这个线索反推问题。我调试驱动时最常用的工具组合是: dmesg看驱动状态、ls -l /dev/确认节点、strace跟踪用户态系统调用。strace能确认用户态是否真的发起了open/read调用帮你判断是用户态的问题还是驱动内的响应有问题。5. 内核态与用户态数据交互copy_*系列函数的理解和防坑5.1 为什么不能直接解引用用户空间指针新手最常犯的严重错误是直接在驱动里写char *kbuf (char *)buf; // buf是用户空间指针 printk(%s\n, kbuf);这么做的后果是极其危险的内核态错误。内核访问用户指针时对应页面可能不在物理内存中甚至压根没被分配到用户态进程随时可能被换出。现代CPU还需要特殊页表机制才能访问用户空间直接解引用轻则触发缺页异常重则导致内核Oops并影响整个系统稳定。这也是为什么Linux专门提供了copy_to_user和copy_from_user它们内部会做地址合法性检查、安全地处理页面缺失、并正确处理被换出页面。5.2 copy_to_user和copy_from_user的正确姿势在3.3节的read/write实现里已经用到过这里再展开讲讲原理和边界。copy_to_user的第一参数是目标用户端地址第二参数是源内核地址第三参数是字节数。它返回未被拷贝的字节数而不是错误码。所以判断失败的标准是返回值非零正常时为0。对于跨页边界的情况内核的copy函数已做了完整处理但我们自己要小心缓冲区索引计算的边界溢出。比如读取位置ppos为4090要读10字节而缓冲区只有4096字节直接按“count”执行就会越界。所以必须像上面的实现里那样逐一计算输入位置和剩余空间再决定实际拷贝数量。我在写大数据量驱动时统一采用一个“剩余量对照表”查看ppos和count的关系这种方法简单且不容易漏边界。5.3 位置指针ppos的正确管理ppos每个打开的文件实例各自持有属于文件级别的私有状态不是驱动全局状态。这意味着A进程打开设备文件读到了中间位置B进程打开同一个设备仍然从0开始两者互不干扰。实际驱动时常常需要对ppos做限制尤其在只支持顺序读的设备上可以强制实现为“忽略ppos直接从头读”。这个操作很简单在read里不更新ppos即可。但如果你的设备需要支持随机访问则必须让read/write正确推进ppos并在遇到非法偏移时返回-EINVAL。6. 常见问题速查从加载到运行的所有坑6.1 最常见问题排查表我在指导学生和自己在开发中遇到的问题几乎都能归进下面几类列个表一目了然现象可能原因排查方向insmod报“Invalid module format”内核版本与模块编译版本不一致检查uname -r和编译环境是否同一内核insmod报“Operation not permitted”系统安全模块限制检查secure boot设置必要时签名模块dmesg提示“No such device”cdev_add失败或设备号分配失败查看完整调用链日志检查设备号是否被占用/dev节点没有自动出现device_create没执行或class_create失败检查正确顺序class_create必须早于device_createopen设备返回“No such file or directory”设备节点不存在或主设备号不对确认/dev下节点和dmesg里的major是否一致write一段数据后read读不到ppos未重置或驱动read实现有误用户态lseek回0驱动里检查ppos更新逻辑打开设备后rmmod报“Module is in use”没有实现release或模块引用计数未正确管理检查file_operations的owner字段和release是否实现6.2 一个经典陷阱模块卸载与设备占用经常有人遇到rmmod时提示“Module is in use”明明自己已经关闭了所有打开的fd。这往往是file_operations结构体里的owner字段没设置。owner字段的作用是每次设备节点被打开时内核会自动增加对应模块的引用计数关闭时递减如果owner是空的计数不会正确维护内核会认为模块一直被占用。我在一次项目调试中遇到过更隐蔽的情形用户态程序崩溃退出但没有正常关闭fd导致模块引用计数卡住。因为release在进程结束时会被内核调用所以最终该fd会被释放只在极少数情况下才会遗留引用。遇到这类问题除了代码逻辑排查还可以用lsof /dev/chardev_demo查看哪个进程还拽着这个设备并行kill掉即可。查这些引用关系时lsof是你的好帮手。6.3 缓冲区越界的惨痛教训一个“小问题”可能造成完全不可预知的系统崩溃。有一次我写一个模拟设备驱动缓冲区定义256字节测试脚本却一次性write了2KB。没有防越界的写法直接导致copy_from_user把数据拷到了kernel_buf之外的地址立即触发内核Oops系统直接重启。整个过程没有警告没有错误码就是一瞬间崩溃。从此之后我的所有read/write实现心里都有一道公式实际可读写长度 min(count, BUF_SIZE - *ppos);每个驱动代码里几乎都附带这个计算并且不仅检查count还要检查ppos或count是否变成负数。用户态传过来的负值count是真实存在的fork时别人导入的数据稍不留神就把size_t的符号搞反进而产生不可想象的大数后面的缓冲区计算直接失败。内核编程里永远不要相信用户态传进来的任何数字因为不得不防御。6.4 使用工具排查命令行当驱动出现问题我不推荐死盯代码应该先用工具排除容易解决的部分。优先级是# 1. 确认设备节点存在 ls -l /dev/chardev_demo # 2. 确认主设备号和驱动是否匹配 cat /proc/devices | grep chardev_demo # 3. 查看内核日志 dmesg | tail -30 # 4. 追踪用户态系统调用 strace -e open,read,write ./test_demo # 5. 确认模块加载状态 lsmod | grep my_driver这几步能筛查掉绝大多数低级问题剩下才是纯粹的驱动逻辑问题这时候才建议深入调试用pr_info在关键路径上加日志。7. 从基础迈向实用并发、阻塞和ioctl怎么进阶7.1 临界区保护与并发控制前面实现的demo驱动有一个天生缺陷它没有考虑并发访问。如果两个进程同时对这个设备写数据或者一个在读一个在写最终数据很可能是错乱的。内核环境下的并发来源太多不只是用户态多进程还有中断上下文、CPU多核同时执行。字符设备的read/write里加锁几乎是进入真实驱动开发的必修课。最基础的用法是互斥锁mutexstatic struct mutex demo_mutex; mutex_init(demo_mutex); static ssize_t demo_read(...) { mutex_lock(demo_mutex); // 临界区操作 mutex_unlock(demo_mutex); }注意在read/write里避免长时间持锁尽量拷贝数据前后都别做太多逻辑否则并发性能会下降高流量设备还会引起进程阻塞。锁的设计在真实驱动里会区分读写锁用RCU或seq lock等方式来平衡性能但这些基础概念必须先掌握。7.2 实现阻塞式访问wait_queue的用法很多真实字符设备比如按键、串口数据到来必须是阻塞式工作方式用户态read时如果内核里没有数据进程应该睡眠等待直到硬件把数据准备好再唤醒。等待队列wait_queue解决的就是这一问题。基本写法static wait_queue_head_t demo_wq; static int data_ready; wait_event_interruptible(demo_wq, data_ready); // 当数据准备好时 data_ready 1; wake_up_interruptible(demo_wq);核心设计点条件在判断和睡眠的间隙不能被其他上下文修改需要配合锁使用。wait_event_interruptible返回值为非0表示被信号中断驱动可以返回-ERESTARTSYS让用户态重试。不处理信号中断的话用户态read可能无法通过CtrlC终止体验非常糟糕。等待队列是进阶第一步我建议学完基础后立刻动手去实现一个事件驱动设备。7.3 ioctl设备控制的“万能接口”字符设备除了read/write还需要ioctl实现对硬件的控制比如设置波特率、切换工作模式、读取状态寄存器。ioctl的实现基于cmd参数本质上是在用户态和内核态之间传递一个整数和一个用户指针。static long demo_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) { switch (cmd) { case DEMO_SET_BUFSIZE: if (copy_from_user(new_size, (void __user *)arg, sizeof(new_size))) return -EFAULT; // 更新缓冲大小 break; case DEMO_GET_STATUS: if (copy_to_user((void __user *)arg, status, sizeof(status))) return -EFAULT; break; default: return -ENOTTY; } }ioctl的cmd一般情况下会使用一些宏来生成比如_IO、_IOR、_IOW用于编码方向和大小这是内核社区的标准做法就是为了让驱动的ioctl命令和第三方驱动的命令不冲突同时能被内核通用层识别方向。就直接用数字硬编码将来一旦和别的驱动撞上调试起来极痛苦。宏生成方式如下#define DEMO_IOCTL_SET_BUF _IOW(D, 1, int) #define DEMO_IOCTL_GET_STA _IOR(D, 2, int)7.4 关于学习路径的一个建议字符设备作为基础之后建议的顺序是先掌握并发和阻塞整明白自旋锁、互斥锁、等待队列再去学平台设备和设备树。因为现代Linux驱动无论你写什么外设最后都是通过平台总线、设备树匹配和驱动核心层打交道你再也不会像这个Demo一样在module_init里手工注册一切而是通过probe回调被内核自动调用。但底层的核心依然是file_operations那一套。我见过很多人直接跳到设备树和平台驱动结果遇到问题根本不知道底层为什么出错因为他们连最简单的字符设备驱动都没有亲手调试过。先把基础这里走通后面是水到渠成的事。8. 最后分享一点个人经验写驱动和写应用完全是两种心态。应用层程序出错最多进程崩掉重启就是驱动出错最小代价是系统重启最可怕的是直接损坏整个文件系统或硬件控制器状态。我在刚学内核的时候就因为一个没检查返回值的copy_from_user把整个虚拟机的磁盘搞到无法识别不得不重建环境。后来养成的习惯是只要是和用户态接壤的边界函数必须检查返回值凡是涉及缓冲区的计算必须做边界判断凡是拿到的资源必须在每个错误路径上释放。字符设备驱动是整个内核开发的根基别觉得它简单就草草跳过基础驱动的精细程度决定你未来写复杂驱动的质量。写一个驱动dmesg各阶段日志检查一遍用户态测试程序按正常、越界、并发三类场景跑一遍这套流程走顺之后再看内核里的其他子系统方向感会完全不同。