1. 内核模块符号解析与依赖机制深度剖析1.1 模块编译的本质分离编译与延迟链接内核模块.ko文件的构建过程与用户空间可执行程序存在根本性差异。模块编译仅执行前端编译compilation不进行后端链接linking。这一设计决策并非技术妥协而是内核模块化架构的核心基石。以一个典型的字符设备驱动模块vser.ko为例其源码中调用了内核提供的printk()函数#include linux/kernel.h #include linux/module.h static int __init vser_init(void) { printk(vser_init\n); return 0; } static void __exit vser_exit(void) { printk(vser_exit\n); } module_init(vser_init); module_exit(vser_exit);当执行make命令编译该模块时GCC 仅将 C 代码翻译为机器指令生成一个可重定位目标文件relocatable object file。使用file命令可验证其 ELF 属性# file vser.ko vser.ko: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), BuildID[sha1]0x09ca747e6f75c65v19a5da9102113v98d7cea24, not stripped关键在于relocatable标识——它表明该文件尚未被分配最终的内存地址所有对外部函数和变量的引用都处于“悬空”状态。此时printk()的具体地址在编译阶段是完全未知的。通过nm工具查看符号表可清晰观察到这种“未决”状态# nm vser.ko ... 00000004 d port U printk 00000000 t vser_exit 00000000 t vser_init符号printk的类型为UUndefined即未定义符号。而vser_init和vser_exit的类型为tlocal text表示它们是本模块内部定义的函数。这种符号状态是模块能够独立编译的前提也是内核实现动态加载能力的技术基础。1.2 EXPORT_SYMBOL内核符号导出的底层机制内核模块之所以能调用printk()等核心函数其根本原因在于内核本身通过EXPORT_SYMBOL宏将这些符号显式地暴露给模块子系统。这并非简单的函数声明而是一套精密的、由编译器、链接器和内核加载器协同完成的符号注册与解析机制。1.2.1 导出宏的编译期行为EXPORT_SYMBOL(sym)宏的定义位于linux/export.h头文件中。其核心作用是在编译阶段于目标文件中创建一个特殊的结构体并将其放置在.modinfo或.export段中。以printk为例内核源码中必然存在类似如下声明// kernel/printk/printk.c asmlinkage __visible int printk(const char *fmt, ...) { // 实现细节 } EXPORT_SYMBOL(printk);当 GCC 处理EXPORT_SYMBOL(printk)时会生成一段汇编代码其逻辑等效于// 伪代码示意其行为 struct kernel_symbol __ksymtab_printk { .value printk, .name printk }; __attribute__((section(.ksymtab))) struct kernel_symbol __ksymtab_printk;该结构体包含两个关键字段value指向printk函数的实际地址和name符号的字符串名称。此结构被强制放置在名为.ksymtab的特殊段中。该段在内核镜像vmlinux的链接脚本中被明确定义确保其在内核启动后能被内核自身识别和管理。1.2.2 内核启动时的符号表初始化在内核启动的早期阶段start_kernel()-rest_init()-kernel_init()内核会执行do_basic_setup()其中调用do_initcalls()来运行所有initcall级别的函数。init/main.c中定义的init_exported_symbols()或类似功能的函数会遍历.ksymtab段中的所有struct kernel_symbol结构并将它们注册到内核全局的符号哈希表kallsyms中。这个哈希表是内核符号解析服务的中枢它建立了从符号名称如printk到其内存地址如0xc0123456的映射关系。1.2.3 模块加载时的动态链接当用户执行insmod vser.ko或modprobe vser时内核模块加载器load_module()开始工作。其关键步骤之一便是符号解析symbol resolution扫描未定义符号加载器首先解析vser.ko的.symtab段提取所有类型为U的符号如printk。哈希表查询对于每个未定义符号加载器在内核全局的kallsyms符号哈希表中进行查找。地址填充若查找到匹配项printk则将查得的地址0xc0123456写入vser.ko的.rela.text重定位段中对应的位置。重定位修正加载器根据.rela.text段中的重定位条目修改vser.ko代码段中对printk的调用指令使其跳转到正确的地址。这一过程本质上就是一次运行时的动态链接runtime dynamic linking其原理与用户空间程序链接libc.so完全一致。区别仅在于用户空间的链接由ld-linux.so在进程启动时完成而内核模块的链接则由内核自身的加载器在模块插入时完成。1.3 模块间依赖导出与导入的工程实践当一个模块需要为其他模块提供服务时便引入了模块间的显式依赖关系。这在复杂的驱动架构中极为常见例如一个通用的硬件抽象层HAL模块为多个上层设备驱动提供统一的寄存器访问接口。1.3.1 依赖关系的建立考虑以下两个模块的代码dep.c—— 提供服务的模块#include linux/kernel.h #include linux/module.h // 定义一个全局变量 static int expval 5; // 将其导出供其他模块使用 EXPORT_SYMBOL(expval); // 定义一个函数 static void expfun(void) { printk(expfun\n); } // 使用 EXPORT_SYMBOL_GPL 导出表示该符号仅对 GPL 兼容模块可用 EXPORT_SYMBOL_GPL(expfun); // 模块入口/出口 static int __init dep_init(void) { printk(dep module loaded\n); return 0; } static void __exit dep_exit(void) { printk(dep module unloaded\n); } module_init(dep_init); module_exit(dep_exit); MODULE_LICENSE(GPL);vser.c—— 依赖服务的模块#include linux/init.h #include linux/kernel.h #include linux/module.h // 声明外部符号 extern int expval; extern void expfun(void); static int __init vser_init(void) { printk(vser_init\n); printk(expval: %d\n, expval); expfun(); return 0; } static void __exit vser_exit(void) { printk(vser_exit\n); } module_init(vser_init); module_exit(vser_exit); MODULE_LICENSE(GPL);Makefile构建规则# 必须将两个模块的目标文件都加入 obj-m 列表 obj-m : vser.o dep.o # 或者如果 dep 是基础模块可单独编译 # obj-m : dep.o # obj-m vser.o在此例中dep.ko是提供者Providervser.ko是使用者Consumer。vser.ko对dep.ko形成了单向依赖。1.3.2 依赖管理工具链depmod 与 modules.dep手动管理模块加载顺序是低效且易错的。Linux 内核提供了depmod工具来自动化这一过程。depmod的工作流程如下扫描模块目录depmod遍历/lib/modules/$(uname -r)/下的所有.ko文件。解析符号依赖对每个模块depmod读取其.ko文件的.modinfo段提取depends:字段由MODULE_DEPENDS宏生成以及所有U类型符号。构建依赖图depmod查询内核符号表/lib/modules/$(uname -r)/modules.builtin和已安装模块确定每个U符号由哪个模块提供。生成依赖数据库将分析结果写入/lib/modules/$(uname -r)/modules.dep文件。modules.dep文件是一个纯文本文件其格式为# /lib/modules/5.10.111-64-generic/modules.dep extra/vser.ko: extra/dep.ko extra/dep.ko:每一行的格式为模块路径: 依赖模块路径列表。冒号后的空格分隔的路径即为该模块所直接依赖的模块。modprobe命令正是基于此数据库工作。当执行modprobe vser时modprobe首先在modules.dep中查找vser.ko的依赖项发现其依赖dep.ko。modprobe递归地检查dep.ko是否已加载若未加载则先执行insmod dep.ko。最后modprobe执行insmod vser.ko。这使得modprobe成为比insmod更高级、更智能的模块管理工具。1.3.3 编译时依赖为何必须联合编译一个常见的陷阱是分别编译dep.c和vser.c然后尝试加载。此时vser.ko的nm输出会显示# nm vser.ko ... U expfun U expval但dmesg会输出致命警告WARNING: expfun [/home/ubuntu/driver/module/vser.ko] undefined! WARNING: expval [/home/ubuntu/driver/module/vser.ko] undefined!insmod加载失败并返回-EINVAL错误。根本原因在于编译时的符号可见性。insmod是一个纯粹的加载器它只负责将.ko文件映射到内核空间并执行其init函数。它不具备depmod的符号解析能力也不会去读取modules.dep。insmod要求模块在加载前其所有U符号必须已在内核的全局符号表中注册。当dep.ko和vser.ko分别编译时dep.ko的EXPORT_SYMBOL信息被写入其自身的.ko文件中。vser.ko在编译时其U符号expfun和expval在内核源码树的符号表中是找不到的因为dep.c并非内核的一部分。因此vser.ko的.ko文件中没有关于expfun和expval的任何“提示”insmod在加载时无法知道去哪里寻找它们。解决方案有二联合编译Recommended在Makefile中将两个模块同时列为obj-m让内核的Kbuild系统在同一个构建上下文中处理它们。Kbuild会自动将dep.o的导出符号信息注入到vser.o的构建过程中确保vser.ko的符号表能正确引用dep.ko。内核源码集成将dep.c放入内核源码树如drivers/misc/并修改Kconfig和Makefile使其成为内核的一部分obj-y或obj-m。这样dep的符号在内核启动时就已注册vser.ko即可作为独立模块加载。1.4 模块生命周期与依赖约束模块的加载与卸载并非对称操作依赖关系对卸载过程施加了严格的约束。1.4.1 加载顺序的强制性如前所述insmod要求严格遵守依赖顺序必须先加载提供者模块再加载使用者模块。违反此顺序会导致加载失败。modprobe通过modules.dep数据库自动保证了这一点因此是推荐的加载方式。1.4.2 卸载顺序的强制性卸载顺序与加载顺序相反且具有更强的强制性。必须先卸载使用者模块再卸载提供者模块。这是因为内核维护了一个模块引用计数struct module-refcnt和一个反向依赖链表struct module-modules_which_use_me。当vser.ko加载时内核会将vser添加到dep模块的modules_which_use_me链表中并增加dep的引用计数。执行rmmod dep.ko时内核会检查dep-refcnt。如果该计数大于 0即仍有其他模块在使用它rmmod将立即失败并返回EBUSY错误。dmesg中会记录[ 1234.567890] dep: module is in use by vser只有当vser.ko被成功卸载后dep-refcnt才会降为 0此时rmmod dep.ko才能成功。1.5 实战构建一个最小化的依赖模块示例下面是一个完整的、可直接编译运行的示例用于验证上述理论。hello_dep.c#include linux/init.h #include linux/module.h #include linux/kernel.h static int hello_value 42; static void hello_function(void) { printk(KERN_INFO Hello from hello_dep!\n); } EXPORT_SYMBOL(hello_value); EXPORT_SYMBOL_GPL(hello_function); static int __init hello_dep_init(void) { printk(KERN_INFO hello_dep: module loaded\n); return 0; } static void __exit hello_dep_exit(void) { printk(KERN_INFO hello_dep: module unloaded\n); } module_init(hello_dep_init); module_exit(hello_dep_exit); MODULE_LICENSE(GPL); MODULE_DESCRIPTION(A simple dependency provider module);hello_user.c#include linux/init.h #include linux/module.h #include linux/kernel.h extern int hello_value; extern void hello_function(void); static int __init hello_user_init(void) { printk(KERN_INFO hello_user: module loaded\n); printk(KERN_INFO hello_user: hello_value %d\n, hello_value); hello_function(); return 0; } static void __exit hello_user_exit(void) { printk(KERN_INFO hello_user: module unloaded\n); } module_init(hello_user_init); module_exit(hello_user_exit); MODULE_LICENSE(GPL); MODULE_DESCRIPTION(A simple dependency consumer module);Makefileifneq ($(KERNELRELEASE),) # Kbuild mode obj-m : hello_user.o hello_dep.o else # Standalone make KERNELDIR ? /lib/modules/$(shell uname -r)/build PWD : $(shell pwd) .PHONY: all clean all: $(MAKE) -C $(KERNELDIR) M$(PWD) modules clean: $(MAKE) -C $(KERNELDIR) M$(PWD) clean endif构建与测试命令# 1. 编译 make # 2. 查看依赖关系确认 depmod 已运行 cat /lib/modules/$(uname -r)/modules.dep | grep hello # 3. 使用 modprobe 加载自动处理依赖 sudo modprobe hello_user # 4. 查看内核日志 dmesg | tail -10 # 5. 卸载 sudo modprobe -r hello_user # 此时 hello_dep 仍驻留内存 sudo modprobe -r hello_dep1.6 关键配置与调试技巧1.6.1 BOM 清单核心内核模块构建组件组件说明典型位置kernel-source内核源码树提供头文件和构建系统/usr/src/linux-headers-$(uname -r)build-essentialGCC、make 等编译工具链Ubuntu/Debianlinux-headers-$(uname -r)内核头文件Kbuild所需Ubuntu/Debiankmodmodprobe,depmod,rmmod等用户空间工具所有发行版1.6.2 调试命令速查表命令用途示例nm -D module.ko显示模块的动态符号导出的符号nm -D hello_dep.konm -u module.ko显示模块的未定义符号依赖的符号nm -u hello_user.komodinfo module.ko显示模块的元信息作者、许可证、依赖modinfo hello_user.kodepmod -a重新生成modules.dep数据库sudo depmod -alsmod列出当前已加载的模块及其大小、使用计数lsmod | grep hellodmesg -w实时监控内核日志观察模块加载/卸载信息dmesg -w1.6.3 常见错误与解决方案错误现象根本原因解决方案insmod: ERROR: could not insert module xxx.ko: Invalid parameters模块依赖的符号未找到U符号未解析1. 确保提供者模块已加载2. 使用modprobe替代insmod3. 检查Makefile是否联合编译rmmod: ERROR: Module xxx is in use模块被其他模块引用refcnt 01. 使用lsmod查看谁在使用它2. 先卸载所有使用者模块3. 检查是否有循环依赖WARNING: ... undefined!depmod未运行或modules.dep过期执行sudo depmod -amodprobe: FATAL: Module xxx not found in directory /lib/modules/...模块未安装到标准路径使用sudo insmod ./xxx.ko或sudo cp xxx.ko /lib/modules/$(uname -r)/extra/ sudo depmod -a理解内核模块的符号导出与依赖机制是深入 Linux 驱动开发和内核编程的必经之路。它揭示了内核如何在保持高度模块化的同时又为开发者提供了一个强大而灵活的扩展框架。每一个EXPORT_SYMBOL都是一扇门而modprobe则是那把万能钥匙它们共同构成了 Linux 内核生态繁荣的底层基石。
Linux内核模块符号导出与依赖机制详解
1. 内核模块符号解析与依赖机制深度剖析1.1 模块编译的本质分离编译与延迟链接内核模块.ko文件的构建过程与用户空间可执行程序存在根本性差异。模块编译仅执行前端编译compilation不进行后端链接linking。这一设计决策并非技术妥协而是内核模块化架构的核心基石。以一个典型的字符设备驱动模块vser.ko为例其源码中调用了内核提供的printk()函数#include linux/kernel.h #include linux/module.h static int __init vser_init(void) { printk(vser_init\n); return 0; } static void __exit vser_exit(void) { printk(vser_exit\n); } module_init(vser_init); module_exit(vser_exit);当执行make命令编译该模块时GCC 仅将 C 代码翻译为机器指令生成一个可重定位目标文件relocatable object file。使用file命令可验证其 ELF 属性# file vser.ko vser.ko: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), BuildID[sha1]0x09ca747e6f75c65v19a5da9102113v98d7cea24, not stripped关键在于relocatable标识——它表明该文件尚未被分配最终的内存地址所有对外部函数和变量的引用都处于“悬空”状态。此时printk()的具体地址在编译阶段是完全未知的。通过nm工具查看符号表可清晰观察到这种“未决”状态# nm vser.ko ... 00000004 d port U printk 00000000 t vser_exit 00000000 t vser_init符号printk的类型为UUndefined即未定义符号。而vser_init和vser_exit的类型为tlocal text表示它们是本模块内部定义的函数。这种符号状态是模块能够独立编译的前提也是内核实现动态加载能力的技术基础。1.2 EXPORT_SYMBOL内核符号导出的底层机制内核模块之所以能调用printk()等核心函数其根本原因在于内核本身通过EXPORT_SYMBOL宏将这些符号显式地暴露给模块子系统。这并非简单的函数声明而是一套精密的、由编译器、链接器和内核加载器协同完成的符号注册与解析机制。1.2.1 导出宏的编译期行为EXPORT_SYMBOL(sym)宏的定义位于linux/export.h头文件中。其核心作用是在编译阶段于目标文件中创建一个特殊的结构体并将其放置在.modinfo或.export段中。以printk为例内核源码中必然存在类似如下声明// kernel/printk/printk.c asmlinkage __visible int printk(const char *fmt, ...) { // 实现细节 } EXPORT_SYMBOL(printk);当 GCC 处理EXPORT_SYMBOL(printk)时会生成一段汇编代码其逻辑等效于// 伪代码示意其行为 struct kernel_symbol __ksymtab_printk { .value printk, .name printk }; __attribute__((section(.ksymtab))) struct kernel_symbol __ksymtab_printk;该结构体包含两个关键字段value指向printk函数的实际地址和name符号的字符串名称。此结构被强制放置在名为.ksymtab的特殊段中。该段在内核镜像vmlinux的链接脚本中被明确定义确保其在内核启动后能被内核自身识别和管理。1.2.2 内核启动时的符号表初始化在内核启动的早期阶段start_kernel()-rest_init()-kernel_init()内核会执行do_basic_setup()其中调用do_initcalls()来运行所有initcall级别的函数。init/main.c中定义的init_exported_symbols()或类似功能的函数会遍历.ksymtab段中的所有struct kernel_symbol结构并将它们注册到内核全局的符号哈希表kallsyms中。这个哈希表是内核符号解析服务的中枢它建立了从符号名称如printk到其内存地址如0xc0123456的映射关系。1.2.3 模块加载时的动态链接当用户执行insmod vser.ko或modprobe vser时内核模块加载器load_module()开始工作。其关键步骤之一便是符号解析symbol resolution扫描未定义符号加载器首先解析vser.ko的.symtab段提取所有类型为U的符号如printk。哈希表查询对于每个未定义符号加载器在内核全局的kallsyms符号哈希表中进行查找。地址填充若查找到匹配项printk则将查得的地址0xc0123456写入vser.ko的.rela.text重定位段中对应的位置。重定位修正加载器根据.rela.text段中的重定位条目修改vser.ko代码段中对printk的调用指令使其跳转到正确的地址。这一过程本质上就是一次运行时的动态链接runtime dynamic linking其原理与用户空间程序链接libc.so完全一致。区别仅在于用户空间的链接由ld-linux.so在进程启动时完成而内核模块的链接则由内核自身的加载器在模块插入时完成。1.3 模块间依赖导出与导入的工程实践当一个模块需要为其他模块提供服务时便引入了模块间的显式依赖关系。这在复杂的驱动架构中极为常见例如一个通用的硬件抽象层HAL模块为多个上层设备驱动提供统一的寄存器访问接口。1.3.1 依赖关系的建立考虑以下两个模块的代码dep.c—— 提供服务的模块#include linux/kernel.h #include linux/module.h // 定义一个全局变量 static int expval 5; // 将其导出供其他模块使用 EXPORT_SYMBOL(expval); // 定义一个函数 static void expfun(void) { printk(expfun\n); } // 使用 EXPORT_SYMBOL_GPL 导出表示该符号仅对 GPL 兼容模块可用 EXPORT_SYMBOL_GPL(expfun); // 模块入口/出口 static int __init dep_init(void) { printk(dep module loaded\n); return 0; } static void __exit dep_exit(void) { printk(dep module unloaded\n); } module_init(dep_init); module_exit(dep_exit); MODULE_LICENSE(GPL);vser.c—— 依赖服务的模块#include linux/init.h #include linux/kernel.h #include linux/module.h // 声明外部符号 extern int expval; extern void expfun(void); static int __init vser_init(void) { printk(vser_init\n); printk(expval: %d\n, expval); expfun(); return 0; } static void __exit vser_exit(void) { printk(vser_exit\n); } module_init(vser_init); module_exit(vser_exit); MODULE_LICENSE(GPL);Makefile构建规则# 必须将两个模块的目标文件都加入 obj-m 列表 obj-m : vser.o dep.o # 或者如果 dep 是基础模块可单独编译 # obj-m : dep.o # obj-m vser.o在此例中dep.ko是提供者Providervser.ko是使用者Consumer。vser.ko对dep.ko形成了单向依赖。1.3.2 依赖管理工具链depmod 与 modules.dep手动管理模块加载顺序是低效且易错的。Linux 内核提供了depmod工具来自动化这一过程。depmod的工作流程如下扫描模块目录depmod遍历/lib/modules/$(uname -r)/下的所有.ko文件。解析符号依赖对每个模块depmod读取其.ko文件的.modinfo段提取depends:字段由MODULE_DEPENDS宏生成以及所有U类型符号。构建依赖图depmod查询内核符号表/lib/modules/$(uname -r)/modules.builtin和已安装模块确定每个U符号由哪个模块提供。生成依赖数据库将分析结果写入/lib/modules/$(uname -r)/modules.dep文件。modules.dep文件是一个纯文本文件其格式为# /lib/modules/5.10.111-64-generic/modules.dep extra/vser.ko: extra/dep.ko extra/dep.ko:每一行的格式为模块路径: 依赖模块路径列表。冒号后的空格分隔的路径即为该模块所直接依赖的模块。modprobe命令正是基于此数据库工作。当执行modprobe vser时modprobe首先在modules.dep中查找vser.ko的依赖项发现其依赖dep.ko。modprobe递归地检查dep.ko是否已加载若未加载则先执行insmod dep.ko。最后modprobe执行insmod vser.ko。这使得modprobe成为比insmod更高级、更智能的模块管理工具。1.3.3 编译时依赖为何必须联合编译一个常见的陷阱是分别编译dep.c和vser.c然后尝试加载。此时vser.ko的nm输出会显示# nm vser.ko ... U expfun U expval但dmesg会输出致命警告WARNING: expfun [/home/ubuntu/driver/module/vser.ko] undefined! WARNING: expval [/home/ubuntu/driver/module/vser.ko] undefined!insmod加载失败并返回-EINVAL错误。根本原因在于编译时的符号可见性。insmod是一个纯粹的加载器它只负责将.ko文件映射到内核空间并执行其init函数。它不具备depmod的符号解析能力也不会去读取modules.dep。insmod要求模块在加载前其所有U符号必须已在内核的全局符号表中注册。当dep.ko和vser.ko分别编译时dep.ko的EXPORT_SYMBOL信息被写入其自身的.ko文件中。vser.ko在编译时其U符号expfun和expval在内核源码树的符号表中是找不到的因为dep.c并非内核的一部分。因此vser.ko的.ko文件中没有关于expfun和expval的任何“提示”insmod在加载时无法知道去哪里寻找它们。解决方案有二联合编译Recommended在Makefile中将两个模块同时列为obj-m让内核的Kbuild系统在同一个构建上下文中处理它们。Kbuild会自动将dep.o的导出符号信息注入到vser.o的构建过程中确保vser.ko的符号表能正确引用dep.ko。内核源码集成将dep.c放入内核源码树如drivers/misc/并修改Kconfig和Makefile使其成为内核的一部分obj-y或obj-m。这样dep的符号在内核启动时就已注册vser.ko即可作为独立模块加载。1.4 模块生命周期与依赖约束模块的加载与卸载并非对称操作依赖关系对卸载过程施加了严格的约束。1.4.1 加载顺序的强制性如前所述insmod要求严格遵守依赖顺序必须先加载提供者模块再加载使用者模块。违反此顺序会导致加载失败。modprobe通过modules.dep数据库自动保证了这一点因此是推荐的加载方式。1.4.2 卸载顺序的强制性卸载顺序与加载顺序相反且具有更强的强制性。必须先卸载使用者模块再卸载提供者模块。这是因为内核维护了一个模块引用计数struct module-refcnt和一个反向依赖链表struct module-modules_which_use_me。当vser.ko加载时内核会将vser添加到dep模块的modules_which_use_me链表中并增加dep的引用计数。执行rmmod dep.ko时内核会检查dep-refcnt。如果该计数大于 0即仍有其他模块在使用它rmmod将立即失败并返回EBUSY错误。dmesg中会记录[ 1234.567890] dep: module is in use by vser只有当vser.ko被成功卸载后dep-refcnt才会降为 0此时rmmod dep.ko才能成功。1.5 实战构建一个最小化的依赖模块示例下面是一个完整的、可直接编译运行的示例用于验证上述理论。hello_dep.c#include linux/init.h #include linux/module.h #include linux/kernel.h static int hello_value 42; static void hello_function(void) { printk(KERN_INFO Hello from hello_dep!\n); } EXPORT_SYMBOL(hello_value); EXPORT_SYMBOL_GPL(hello_function); static int __init hello_dep_init(void) { printk(KERN_INFO hello_dep: module loaded\n); return 0; } static void __exit hello_dep_exit(void) { printk(KERN_INFO hello_dep: module unloaded\n); } module_init(hello_dep_init); module_exit(hello_dep_exit); MODULE_LICENSE(GPL); MODULE_DESCRIPTION(A simple dependency provider module);hello_user.c#include linux/init.h #include linux/module.h #include linux/kernel.h extern int hello_value; extern void hello_function(void); static int __init hello_user_init(void) { printk(KERN_INFO hello_user: module loaded\n); printk(KERN_INFO hello_user: hello_value %d\n, hello_value); hello_function(); return 0; } static void __exit hello_user_exit(void) { printk(KERN_INFO hello_user: module unloaded\n); } module_init(hello_user_init); module_exit(hello_user_exit); MODULE_LICENSE(GPL); MODULE_DESCRIPTION(A simple dependency consumer module);Makefileifneq ($(KERNELRELEASE),) # Kbuild mode obj-m : hello_user.o hello_dep.o else # Standalone make KERNELDIR ? /lib/modules/$(shell uname -r)/build PWD : $(shell pwd) .PHONY: all clean all: $(MAKE) -C $(KERNELDIR) M$(PWD) modules clean: $(MAKE) -C $(KERNELDIR) M$(PWD) clean endif构建与测试命令# 1. 编译 make # 2. 查看依赖关系确认 depmod 已运行 cat /lib/modules/$(uname -r)/modules.dep | grep hello # 3. 使用 modprobe 加载自动处理依赖 sudo modprobe hello_user # 4. 查看内核日志 dmesg | tail -10 # 5. 卸载 sudo modprobe -r hello_user # 此时 hello_dep 仍驻留内存 sudo modprobe -r hello_dep1.6 关键配置与调试技巧1.6.1 BOM 清单核心内核模块构建组件组件说明典型位置kernel-source内核源码树提供头文件和构建系统/usr/src/linux-headers-$(uname -r)build-essentialGCC、make 等编译工具链Ubuntu/Debianlinux-headers-$(uname -r)内核头文件Kbuild所需Ubuntu/Debiankmodmodprobe,depmod,rmmod等用户空间工具所有发行版1.6.2 调试命令速查表命令用途示例nm -D module.ko显示模块的动态符号导出的符号nm -D hello_dep.konm -u module.ko显示模块的未定义符号依赖的符号nm -u hello_user.komodinfo module.ko显示模块的元信息作者、许可证、依赖modinfo hello_user.kodepmod -a重新生成modules.dep数据库sudo depmod -alsmod列出当前已加载的模块及其大小、使用计数lsmod | grep hellodmesg -w实时监控内核日志观察模块加载/卸载信息dmesg -w1.6.3 常见错误与解决方案错误现象根本原因解决方案insmod: ERROR: could not insert module xxx.ko: Invalid parameters模块依赖的符号未找到U符号未解析1. 确保提供者模块已加载2. 使用modprobe替代insmod3. 检查Makefile是否联合编译rmmod: ERROR: Module xxx is in use模块被其他模块引用refcnt 01. 使用lsmod查看谁在使用它2. 先卸载所有使用者模块3. 检查是否有循环依赖WARNING: ... undefined!depmod未运行或modules.dep过期执行sudo depmod -amodprobe: FATAL: Module xxx not found in directory /lib/modules/...模块未安装到标准路径使用sudo insmod ./xxx.ko或sudo cp xxx.ko /lib/modules/$(uname -r)/extra/ sudo depmod -a理解内核模块的符号导出与依赖机制是深入 Linux 驱动开发和内核编程的必经之路。它揭示了内核如何在保持高度模块化的同时又为开发者提供了一个强大而灵活的扩展框架。每一个EXPORT_SYMBOL都是一扇门而modprobe则是那把万能钥匙它们共同构成了 Linux 内核生态繁荣的底层基石。
