嵌入式Linux开发6——老API字符设备驱动 - 从零开始踩坑实录仓库已经开源所有教程主线内核移植跑新版本imx-linux/uboot都在这里欢迎各位大佬观摩喜欢的话点个⭐仓库地址https://github.com/Awesome-Embedded-Learning-Studio/imx-forge静态网页https://awesome-embedded-learning-studio.github.io/imx-forge/马上准备写驱动了可以先看看如何配置clangd环境确保写代码丝滑补全和0红线前面的一篇就是环境配置篇前言我们为什么要折腾这个前面几节我们把理论都过了一遍MMU 怎么把虚拟地址变成物理地址内核为什么不让我们直接访问物理内存ioremap和readl/writel这对搭档怎么帮我们绕过这些限制。但说实话光看理论真的很虚代码不跑起来永远不知道哪里会炸。现在我们要写一个字符设备驱动。但先别急着去搞硬件我们从最简单的虚拟字符设备开始。这个驱动不会点亮任何 LED它只是在内核和用户空间之间传递数据。为什么要从虚拟设备开始因为这样可以让我们专注于核心概念不用操心硬件寄存器、时钟使能、GPIO 配置这些乱七八糟的细节。出问题了也更容易定位毕竟排除了硬件因素这个大变量。第一步先搞清楚老API是什么说实话当我们第一次看到register_chrdev这个函数的时候感觉还挺友好的。在老内核时代注册一个字符设备驱动真的非常简单简单到一行代码就能搞定intregister_chrdev(unsignedintmajor,constchar*name,conststructfile_operations*fops);参数也就三个major 是主设备号name 是设备名称会出现在/proc/devices里fops 是指向file_operations结构体的指针。返回值也很直观成功就返回主设备号失败就返回负数错误码。但事情没这么简单。当我们真正开始写代码的时候问题一个接一个地冒出来了。第二步第一次尝试——写个最简单的版本我们先写一个最基本的版本看看会发生什么。首先引入必要的头文件#includelinux/fs.h#includelinux/uaccess.h#includelinux/init.h#includelinux/kernel.h#includelinux/module.h#includelinux/printk.h#includelinux/string.h然后定义一些宏和全局变量。这里我们硬编码了主设备号为200说实话这个做法其实很粗糙但作为第一次实验我们先把路跑通再谈规范staticconstchar*CHARDEV_NAMEAES_Chardev;staticconstintCHARDEV_MAJOR200;#defineBUFFER_SIZE(100)staticcharbuf_read[BUFFER_SIZE]{0};staticcharbuf_write[BUFFER_SIZE]{0};#undefBUFFER_SIZEstaticconstchar*kFixedMessageHello from Kernel! Message Sent from the module!;接下来是file_operations结构体。Linux 驱动最核心的设计思想就是把硬件抽象成一个文件。用户程序用open、read、write来操作设备而内核需要知道当这些系统调用发生时该跳转到哪段代码执行。这个映射关系就定义在file_operations结构体里。我们先写一个最简单的 read 函数staticssize_taes_chardev_read(structfile*filp,char__user*buf,size_tcnt,loff_t*offt){memcpy(buf_read,kFixedMessage,strlen(kFixedMessage)1);constunsignedlongkRetValuecopy_to_user(buf,buf_read,cnt);returnkRetValue;}看起来没什么问题对吧我们把固定消息复制到缓冲区然后用copy_to_user把数据发送给用户空间。其他几个函数也更简单基本上就是打印个日志就完事staticintaes_chardev_open(structinode*inode,structfile*filp){pr_info(Device: %s called open!\n,CHARDEV_NAME);return0;}staticssize_taes_chardev_write(structfile*filp,constchar__user*buf,size_tcnt,loff_t*offt){pr_info(Device: %s called write!\n,CHARDEV_NAME);returncnt;}staticintaes_chardev_release(structinode*inode,structfile*filp){pr_info(Device: %s called close!\n,CHARDEV_NAME);return0;}staticstructfile_operationsfops{.ownerTHIS_MODULE,.openaes_chardev_open,.readaes_chardev_read,.writeaes_chardev_write,.releaseaes_chardev_release,};最后是模块的加载和卸载函数staticint__initchardev_base_00_init(void){constintkResultregister_chrdev(CHARDEV_MAJOR,CHARDEV_NAME,fops);if(kResult!0){pr_warn(Failed to register the chardev region! kResult%d\n,kResult);returnkResult;}pr_info(%s load successfully!\n,CHARDEV_NAME);returnkResult;}staticvoid__exitchardev_base_00_exit(void){pr_info( chardev_base_00 module unloaded \n);unregister_chrdev(CHARDEV_MAJOR,CHARDEV_NAME);pr_info(\n);}module_init(chardev_base_00_init);module_exit(chardev_base_00_exit);MODULE_LICENSE(GPL);MODULE_AUTHOR(Charliechen114514);MODULE_DESCRIPTION(Basic Char Dev Usage);MODULE_VERSION(1.0);到这里我们觉得应该没什么问题了赶紧编译一下看看效果。第三步第一次运行——缓冲区溢出警告编译很顺利make一把过生成了chardev_base_00_driver.ko文件。我们把驱动拷贝到开发板然后加载insmod chardev_base_00_driver.ko加载成功现在创建设备节点mknod/dev/aes c2000然后试试读取cat/dev/aes直接炸了[ 138.137579] Device: AES_Chardev called open! [ 138.137668] Device: AES_Chardev called read! [ 138.137684] ------------[ cut here ]------------ [ 138.137695] WARNING: mm/maccess.c:234 at __copy_overflow0x24/0x34 [ 138.158630] Buffer overflow detected (100 4096)! ← 关键信息 [ 138.163512] Modules linked in: chardev_base_00_driver(O) [ 138.168890] CPU: 0 UID: 0 PID: 66 Comm: cat Tainted: G W O 7.0.0-rc4-g113ae7b4decc-dirty #1 [ 138.179550] Tainted: [W]WARN, [O]OOT_MODULE [ 138.183924] Hardware name: Freescale i.MX6 Ultralite (Device Tree) [ 138.190125] Call trace: [ 138.190149] unwind_backtrace from show_stack0x10/0x14 [ 138.197984] show_stack from dump_stack_lvl0x38/0x48 [ 138.203106] dump_stack_lvl from __warn0x84/0xec [ 138.207881] __warn from warn_slowpath_fmt0x94/0xc8 [ 138.212906] warn_slowpath_fmt from __copy_overflow0x24/0x34 [ 138.218719] __copy_overflow from aes_chardev_read0x54/0xdc [chardev_base_00_driver]看到堆栈跟踪我们才意识到问题出在哪里。关键信息在这一行Buffer overflow detected (100 4096)!我们回头看看代码问题一下子就清楚了。我们的缓冲区buf_read只有 100 字节但cat程序默认请求 4096 字节一页内存。我们直接把用户请求的大小cnt传给了copy_to_user结果就是试图从 100 字节的缓冲区复制 4096 字节。这就是为什么内核会检测到缓冲区溢出。说实话这个坑我们真的踩了很久。一开始还以为是copy_to_user用法有问题翻半天内核文档才发现问题出在长度检查上。修复方法也很简单取实际长度和请求长度的较小值就可以了staticssize_taes_chardev_read(structfile*filp,char__user*buf,size_tcnt,loff_t*offt){unsignedintlenstrlen(kFixedMessage);// 防止溢出取实际长度和请求长度的较小值if(cntlen)lencnt;if(copy_to_user(buf,kFixedMessage,len)){pr_warn(Failed to send data to user\n);return-EFAULT;}pr_info(Successfully Send data to user!\n);returnlen;}这里我们还做了一处改动直接用kFixedMessage而不是先复制到buf_read反正copy_to_user会安全地处理数据拷贝。第四步第二次运行——无限循环噩梦修复了缓冲区溢出问题我们重新编译加载然后再次运行cat /dev/aes。这次没有报错了但是出现了一个新问题cat/dev/aes Hello from Kernel!Message Sent from the module!Hello from Kernel!Message Sent from the module!Hello from Kernel!Message Sent from the module!Hello from Kernel!Message Sent from the module!...[无限循环需要 CtrlC 停止]屏幕上不停地输出相同的消息只能用 CtrlC 强制终止。这个问题真的困扰了我们很久。后来我们仔细想了想cat程序的工作原理才明白问题所在。cat程序的内部逻辑大概是这个样子的while(1){nread(fd,buf,4096);if(n0)break;// EOF文件结束← 关键write(1,buf,n);}我们的驱动问题在于每次read()调用都返回数据从不返回 0EOF。所以cat认为文件还没结束就一直读下去。解决办法是用偏移量来管理文件位置。第一次read()之后更新偏移量后续调用检测到偏移量大于 0 就返回 0staticssize_taes_chardev_read(structfile*filp,char__user*buf,size_tcnt,loff_t*offt){pr_info(Device: %s called read!\n,CHARDEV_NAME);// 已经读过一次 → 返回 EOFif(*offt0){return0;// 终止读取循环}unsignedintlenstrlen(kFixedMessage);if(cntlen)lencnt;// 更新偏移量关键*offtlen;if(copy_to_user(buf,kFixedMessage,len)){pr_warn(Failed to send data to user\n);return-EFAULT;}pr_info(Successfully Send data to user!\n);returnlen;}修复后再试一次cat/dev/aes Hello from Kernel!Message Sent from the module![正常结束不再循环]第五步第三个坑——返回值语义错误在调试过程中我们还发现了一个更隐蔽的问题返回值的语义错误。这个问题之所以隐蔽是因为它不会直接导致程序崩溃而是会让用户程序收到错误的信息。我们一开始的代码是这样的constunsignedlongkRetValuecopy_to_user(buf,buf_read,cnt);returnkRetValue;// ❌ 错误这里的问题在于copy_to_user的返回值语义和read系统调用的返回值语义是相反的。copy_to_user返回的是未能复制的字节数如果完全成功就返回 0而read系统调用应该返回成功读取的字节数。如果直接返回copy_to_user的结果用户程序就会以为读取了 0 字节。正确的做法是检查copy_to_user的返回值如果非 0 就返回错误码否则返回实际传输的字节数if(copy_to_user(buf,kFixedMessage,len)){return-EFAULT;// 返回错误码}returnlen;// 返回实际传输的字节数write函数也是类似的处理方式staticssize_taes_chardev_write(structfile*filp,constchar__user*buf,size_tcnt,loff_t*offt){pr_info(Device: %s called write!\n,CHARDEV_NAME);size_tlencnt;// 防止溢出if(lensizeof(buf_write)-1)lensizeof(buf_write)-1;if(copy_from_user(buf_write,buf,len)){pr_warn(Failed to receive data from user\n);return-EFAULT;}buf_write[len]\0;pr_info(Kernel module has received from data: %s\n,buf_write);memset(buf_write,0,cnt);returnlen;}这里多说一句千万别以为copy_from_user和copy_to_user只是简单的memcpy。这两个函数做了很多额外的工作比如检查用户空间指针是否有效、处理页面错误等。直接解引用用户空间的指针是绝对禁止的那会导致内核崩溃或者安全漏洞。第六步完整的测试代码到这里我们的驱动代码终于能正常工作了。但为了验证它的功能我们还需要一个用户空间的测试程序#includestdio.h#includeunistd.h#includesys/types.h#includesys/stat.h#includefcntl.h#includestdlib.h#includestring.hintmain(intargc,char*argv[]){intfd,retvalue;char*filename;unsignedchardatabuf[1];if(argc!3){printf(Error Usage!\r\n);return-1;}filenameargv[1];fdopen(filename,O_RDWR);if(fd0){printf(file %s open failed!\r\n,argv[1]);return-1;}databuf[0]atoi(argv[2]);/* 向/dev/aes 文件写入数据 */retvaluewrite(fd,databuf,sizeof(databuf));if(retvalue0){printf(Control Failed!\r\n);close(fd);return-1;}retvalueclose(fd);if(retvalue0){printf(file %s close failed!\r\n,argv[1]);return-1;}return0;}编译测试程序arm-linux-gnueabihf-gcc aes_chardev_test.c-oaes_chardev_test然后拷贝到开发板测试# 测试写入./aes_chardev_test /dev/aes123# 查看内核日志dmesg|tail-10如果一切正常你应该能在内核日志里看到驱动打印的消息。第七步老API的问题暴露出来了折腾完这一轮我们开始感觉到老API的一些问题。这些问题在一开始的时候不太明显但当你开始写更复杂的驱动时它们会变得越来越烦人。第一个问题是设备号冲突。我们硬编码了主设备号为200这个数字是我们猜的假设它没有被占用。但如果系统里已经有驱动占用了这个号我们的驱动注册就会失败。正规的做法应该是让内核动态分配一个空闲的设备号但老API在这方面做得不好。第二个问题是资源浪费。我们的驱动只需要一个设备一对设备号但register_chrdev会粗暴地霸占整个主设备号下的所有 1048576 个次设备号。在一个资源紧张的嵌入式系统里这简直是在犯罪。第三个问题是手动创建节点。每次加载驱动后我们都必须手动执行mknod命令创建/dev节点。如果忘记这一步用户程序就无法访问设备。而且用户必须知道正确的主设备号和次设备号这对新手来说很不友好。这些问题就是为什么内核后来引入了新的字符设备API。下一章我们会学习新API它虽然代码量多一些但解决了上述所有问题动态分配设备号避免冲突按需申请设备号避免浪费还能自动创建设备节点无需手动 mknod。调试技巧分享在这一章的折腾过程中我们总结了一些有用的调试技巧希望能帮读者少走弯路。查看内核日志是基本操作# 实时监控dmesg-w# 查看最近的日志dmesg|tail-20# 过滤特定消息dmesg|grepAES_Chardev# 清空日志方便重新观察dmesg-c理解堆栈跟踪很重要。当内核打印出 Call trace 时不要被那一堆地址吓到。关键信息通常在最后几行比如__copy_overflow from aes_chardev_read0x54/0xdc这告诉我们在aes_chardev_read函数里调用了__copy_overflow偏移量是0x54。根据这个信息你可以快速定位到问题代码。调试步骤建议首先确认问题现象然后查看内核日志分析错误信息定位问题代码最后修复验证。这个流程看起来很基础但当我们急着解决问题的时候很容易跳过某些步骤导致反而花了更多时间。本章小结说实话这一章我们踩的坑比预想的要多。但正是这些坑让我们真正理解了字符设备驱动的核心概念。我们学到了什么第一永远不要信任用户输入。用户提供的cnt可能比你想象的要大得多必须做好边界检查。第二理解并实现正确的文件语义。read()必须在适当的时候返回 0EOF否则用户程序会陷入无限循环。第三正确处理返回值。copy_to_user和copy_from_user的返回值语义和系统调用不同不能直接返回。第四使用偏移量管理文件位置。这不仅是实现正确语义的需要也是维护驱动状态的重要手段。老APIregister_chrdev虽然简单直接但它的局限性也很明显。下一章我们会学习新字符设备驱动API它会让你看到更规范、更优雅的驱动开发方式。但不管用哪种API本章学到的这些核心概念都是通用的。相关文档新字符设备驱动 API 概览新 API 驱动代码深度解析相关阅读深入理解Linux模块——模块参数与内核调试让模块活起来的魔法 - 相似度 100%深入理解Linux模块——内核模块编译与加载详解从 Makefile 到 insmod 的完整旅程 - 相似度 100%嵌入式Linux驱动开发3——内核模块机制 - Linux 的插件系统 - 相似度 100%