嵌入式Linux驱动开发3——内核模块机制 - Linux 的插件系统仓库已经开源所有教程主线内核移植跑新版本imx-linux/uboot都在这里欢迎各位大佬观摩喜欢的话点个⭐仓库地址https://github.com/Awesome-Embedded-Learning-Studio/imx-forge静态网页https://awesome-embedded-learning-studio.github.io/imx-forge/这算重新介绍的部分刚好给后面的驱动内容进行预热前言模块到底是什么在前面的章节中我们一直在说内核模块这个词但从来没有深入解释到底什么是内核模块为什么需要它它是如何工作的这一章我们要揭开内核模块的神秘面纱。说实话理解模块机制很重要因为这是我们开发驱动的基础。如果你不知道模块是怎么加载和卸载的写起代码来就会感觉在云里雾里。静态编译 vs 动态加载从重启到热插拔在 Linux 的早期内核是一个单一的、庞大的可执行文件。你想添加新功能没问题但代价很大。你得修改内核源码重新编译整个内核然后重启系统。这个过程耗时很长而且很烦人。每次改一行代码都要重启这个开发效率真的让人血压拉满。后来内核开发者引入了**模块Module**机制允许在运行时动态地加载和卸载代码。这就像是给内核装上了一个插件系统。你可以把模块理解成一个内核插件。它是一段编译好的内核代码可以在系统运行时插入内核也可以在不需要时移除。整个过程不需要重启系统就像你在浏览器里安装和卸载扩展一样方便。这个机制对驱动开发特别重要。想象一下如果你每次修改驱动代码都要重启系统那调试起来得有多痛苦。有了模块机制你只需要卸载旧模块加载新模块几秒钟就能完成测试。这对开发效率的提升是巨大的。模块的生命周期从加载到卸载一个内核模块从诞生到消亡会经历几个阶段。理解这个生命周期对于编写正确的驱动至关重要。我们先从整体上看一遍流程。首先是编译阶段。你写的源码.c 文件通过内核构建系统编译成一个 .ko 文件Kernel Object。这个文件包含了模块的代码、元数据、符号信息等等。然后是加载阶段。用户执行insmod命令内核读取 .ko 文件解析 ELF 格式重定位符号地址解析模块依赖最后调用模块的初始化函数。如果初始化函数返回 0加载成功否则加载失败。接下来是运行阶段。模块在这个阶段响应系统调用、处理中断、管理设备和数据。这个阶段可能持续几秒也可能持续几天取决于你的需求。最后是卸载阶段。用户执行rmmod命令内核检查模块的引用计数。如果引用计数为 0内核调用模块的清理函数释放内存完全移除模块。这个生命周期看起来简单但每个阶段都有需要注意的细节。我们来一步步拆解。module_init 和 module_exit入口和出口在模块代码里你会看到两个奇怪的宏module_init()和module_exit()。这两个宏是模块机制的核心。module_init()的作用是告诉内核“这个函数是初始化函数加载模块时调用它”。module_exit()则告诉内核“这个函数是清理函数卸载模块时调用它”。这两个函数的写法有固定的套路。初始化函数必须用__init宏标记返回int成功返回 0失败返回负数错误码。清理函数用__exit宏标记返回void因为它不需要也不能失败。staticint__initmy_module_init(void){printk(KERN_INFOModule is loading\n);// 做初始化工作return0;// 返回 0 表示成功}staticvoid__exitmy_module_exit(void){printk(KERN_INFOModule is unloading\n);// 做清理工作}module_init(my_module_init);module_exit(my_module_exit);这里有个有趣的细节。__init和__exit宏不仅仅是标记它们还会把代码放到特殊的 ELF 段里。__init段的代码在初始化完成后会被释放掉节省内存。__exit段的代码在模块被编译进内核而不是作为模块时会被完全丢弃因为这种情况下模块永远不会被卸载。模块参数运行时配置还记得我们在前面看到的debug_level参数吗insmod modern_print_kernel_base00_driver.kodebug_level2这就是模块参数它允许在加载模块时传递配置信息。这个机制真的很实用你可以用同一个模块二进制文件通过不同的参数实现不同的行为不用重新编译。定义模块参数的套路也很固定。首先定义一个变量作为参数的存储然后用module_param()宏注册它。你还可以用MODULE_PARM_DESC()添加参数说明。staticintdebug_level1;// 默认值module_param(debug_level,int,0644);MODULE_PARM_DESC(debug_level,Debug level (0none, 1info, 2debug));module_param()的第二个参数是类型。常用的类型有int整数、bool布尔值、charp字符串指针。第三个参数是权限它决定这个参数是否在 sysfs 中可见以及是否可以修改。权限参数的含义和文件的权限位一样。0表示不在 sysfs 中显示0444表示只读0644表示 root 可写其他人只读。如果你希望参数可以在运行时修改就用0644。加载模块后你可以通过 sysfs 修改参数。这个功能在调试时特别有用你可以动态调整日志级别不用卸载模块重新加载。# 查看当前参数值cat/sys/module/my_module/parameters/my_param# 动态修改参数echo10/sys/module/my_module/parameters/my_param模块依赖不是孤岛模块不是孤立的它们之间可能存在依赖关系。比如你的驱动用到了 USB 核心的功能那它就依赖usbcore模块。如果依赖不满足模块加载会失败。查看模块依赖用modinfo命令。它会列出模块的元数据包括依赖哪些其他模块。modinfo my_module.ko# 输出# filename: my_module.ko# description: My test driver# license: GPL# depends: usbcore# vermagic: 6.12.49 SMP mod_unload modversions说到加载命令这里有个常见的问题insmod和modprobe有什么区别两者都能加载模块但modprobe更智能。它会自动处理依赖关系如果模块依赖usbcoremodprobe会先加载usbcore再加载你的模块。insmod就不会这么贴心你得自己手动按顺序加载。引用计数防止误卸载内核通过引用计数来跟踪模块的使用情况防止模块还在被使用时被误卸载。这个机制真的很重要我见过太多新手因为忘记管理引用计数导致系统崩溃。引用计数的原理很简单。每次有对象使用模块时计数加 1每次停止使用时计数减 1。只有当计数为 0 时模块才能被卸载。对于字符设备驱动使用通常对应应用程序打开设备文件。所以你在open函数里要增加引用计数在release函数里要减少引用计数。staticintmy_open(structinode*inode,structfile*filp){try_module_get(THIS_MODULE);// 增加引用计数return0;}staticintmy_release(structinode*inode,structfile*filp){module_put(THIS_MODULE);// 减少引用计数return0;}如果引用计数不为 0 时尝试卸载模块rmmod会失败并报错“Module is in use”。这个保护机制可以防止应用程序还在使用设备时驱动被卸载那会导致不可预测的行为。模块元数据MODULE_* 宏在模块代码里你会看到很多MODULE_*宏。这些宏用于在模块中嵌入元数据信息。MODULE_LICENSE()是必需的。如果模块没有声明许可证内核会拒绝加载并在dmesg中留下警告“module license ‘unspecified’ taints kernel”。内核这么做的原因是有些内核函数只能被 GPL 许可证的代码使用闭源驱动不能调用这些函数。常用的许可证有GPL、GPL v2、Dual BSD/GPL。如果你写的是闭源驱动用Proprietary但会被标记为污染内核。其他元数据宏是可选的但推荐都写上。MODULE_AUTHOR()说明作者MODULE_DESCRIPTION()描述模块功能MODULE_VERSION()标记版本号。这些信息都会出现在modinfo的输出里对维护很有帮助。MODULE_LICENSE(GPL);MODULE_AUTHOR(Your Name emailexample.com);MODULE_DESCRIPTION(Brief description of the module);MODULE_VERSION(1.0);版本控制vermagic 的坑你可能注意到了modinfo输出中的vermagic字段。这是内核的版本控制机制也是新手常踩的坑。vermagicversion magic是一个字符串描述了模块编译时的内核版本和配置。如果模块编译时的内核版本和运行时的内核版本不一致加载会失败。错误信息大概是“disagrees about version of symbol module_layout”。这个问题的原因很简单内核内部数据结构可能在不同版本间发生变化。用老版本编译的模块试图访问新版本的内核结构可能会导致内存错乱。所以内核干脆拒绝加载不匹配的模块。解决方法是重新编译。确保你的模块用当前内核的源码树编译make命令会自动处理版本匹配。当然你可以用--force强制加载但千万别这么干那是在玩火。insmod 和 rmmod 的内部流程我们来深入了解一下insmod和rmmod的底层机制。虽然理解这些不是开发驱动的必需但知道底层发生了什么有助于调试问题。insmod的内部流程是这样的用户空间的insmod命令读取 .ko 文件然后发起finit_module系统调用。内核接管后首先验证模块签名如果启用了模块签名然后检查版本兼容性。接着分配内核内存重定位符号地址把代码里对内核函数的引用解析成实际地址解析模块依赖调用module_init指定的初始化函数最后创建 sysfs 条目。如果任何一步失败整个加载过程回滚模块不会被加载。rmmod的流程相对简单用户空间的rmmod命令发起delete_module系统调用。内核首先检查模块的引用计数如果计数不为 0直接返回错误。如果计数为 0调用module_exit指定的清理函数移除 sysfs 条目释放模块占用的内存。知道这些流程后你就明白为什么有些错误会发生了。比如Unknown symbol错误是因为符号重定位失败——你的模块用到了一个不存在的内核函数。Module is in use错误是因为引用计数不为 0。一个完整的模块示例让我们把上面的知识串起来看一个完整的模块示例。这个模块不做什么实际的事只是演示模块机制的基本框架。#includelinux/module.h#includelinux/init.h#includelinux/kernel.h// 模块参数staticintmy_param1;module_param(my_param,int,0644);MODULE_PARM_DESC(my_param,My integer parameter);// 模块元数据MODULE_LICENSE(GPL);MODULE_AUTHOR(Your Name);MODULE_DESCRIPTION(A complete module example);MODULE_VERSION(1.0);// 初始化函数staticint__initmy_module_init(void){printk(KERN_INFOModule loading...\n);printk(KERN_INFOParameter my_param %d\n,my_param);// 初始化工作printk(KERN_INFOModule loaded successfully!\n);return0;}// 退出函数staticvoid__exitmy_module_exit(void){printk(KERN_INFOModule unloading...\n);printk(KERN_INFOModule unloaded successfully!\n);}module_init(my_module_init);module_exit(my_module_exit);这个例子包含了模块的基本框架。编译、加载、卸载的流程前面讲过了这里不再重复。但你应该能看出来模块开发的核心就是编写init和exit两个函数其他的都是辅助机制。小结这一章我们深入学习了内核模块机制。从概念上讲模块是内核的插件系统允许运行时动态加载代码。从实现上讲模块通过module_init/module_exit宏定义入口和出口函数通过MODULE_*宏声明元数据通过引用计数防止误卸载。模块机制对驱动开发特别重要。它让我们可以快速迭代代码不用每次修改都重启系统。模块参数机制提供了运行时配置能力同一个二进制文件可以适应不同的使用场景。理解了模块机制你就可以开始写真正的驱动了。下一章我们会讲内核调试技术这对驱动开发同样重要。说实话驱动开发离不开调试你会花大量时间在dmesg里找线索。继续阅读04_kernel_print_guide.md 了解内核打印和日志机制或者跳到 06_legacy_chardev.md 看实战代码。相关阅读深入理解Linux模块——模块参数与内核调试让模块活起来的魔法 - 相似度 100%深入理解Linux模块——内核模块编译与加载详解从 Makefile 到 insmod 的完整旅程 - 相似度 100%嵌入式Linux学习指南之设备树——Linux内核设备树编译机制深度解析 - 相似度 80%