用 modprobe -d 可直接查看模块加载时的完整依赖顺序，它基于 modules.dep.bin 静态解析，不校验文件存在性；符号级依赖需查 /proc/kallsyms；编译期依赖靠 nm 和 module.symvers 配合验证。
怎么看模块依赖关系：用 modprobe -D 最直接
想快速知道某个模块加载时会拉哪些依赖，modprobe -D 是唯一能直接输出完整 insmod 顺序的命令。它不校验文件是否存在，也不真正加载，只按 modules.dep.bin 静态解析。
比如查 vfat 模块：
modprobe -D vfat
输出类似：
insmod /lib/modules/$(uname -r)/kernel/fs/fat/fat.ko insmod /lib/modules/$(uname -r)/kernel/fs/vfat/vfat.ko
注意三点：
-
$(uname -r)是实际内核版本，不是占位符；确保/lib/modules/下有对应目录 - 拼错模块名或
.ko文件缺失时，-D仍可能成功输出——它不检查文件存在性 - 这个顺序就是
modprobe vfat实际执行的加载链，但不等于运行时符号级依赖
怎么确认符号级依赖是否满足：看 /proc/kallsyms
模块加载报 Unknown symbol，说明符号没找到，这时候得查运行时符号表。/proc/kallsyms 是唯一反映当前已加载模块真实符号状态的来源。
例如查模块 module_a 是否导出了 shared_func：
cat /proc/kallsyms | grep shared_func
如果输出形如：
ffffffffc1234567 t shared_func [module_a]
说明符号已注册且可见（注意第三列是符号名，方括号里是模块名）。关键看第二列类型：T 表示函数、D 表示已初始化变量，且必须是大写字母（小写 t/d 是局部符号，其他模块不可见）。
常见坑：
- 非 root 用户看到的地址全是
0000000000000000，需用sudo cat /proc/kallsyms - 符号存在但模块未加载，
/proc/kallsyms里不会出现——先insmod module_a.ko再查 -
EXPORT_SYMBOL_GPL导出的符号，若依赖模块许可证非 GPL，即使出现在/proc/kallsyms中也会加载失败
编译期符号依赖怎么查：nm + Module.symvers
开发阶段查跨目录模块依赖，不能只靠运行时工具。nm 和 Module.symvers 才是定位编译问题的核心组合。
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
查一个未加载的 .ko 文件需要哪些符号：
nm module_b.ko | grep "U "
U 表示未定义符号，即它依赖但自己没实现的函数或变量。而 Module.symvers 文件才是告诉编译器“这个符号到底来自哪个模块”的依据。
它的格式是 CSV：
0x2d7b3d5a shared_func drivers/misc/module_a.ko EXPORT_SYMBOL
关键点：
- 必须把导出模块生成的
Module.symvers复制到依赖模块的编译目录，否则make会报undefined reference - CRC 值（第一列）用于校验符号一致性，版本不匹配会导致运行时符号解析失败，错误不明显
-
EXPORT_SYMBOL_GPL和EXPORT_SYMBOL在Module.symvers第四列明确区分，编译器据此判断许可兼容性
depmod -ae 能帮你发现隐性符号问题
depmod 不只是生成 modules.dep，加 -e 参数能暴露那些“模块声称需要、但没人提供”的符号。
运行：
depmod -ae
如果有输出类似：
ERROR: Missing symbol shared_func (from module_b.ko)
说明系统里所有已安装模块中，没有模块导出 shared_func——这时要检查：
- 导出模块是否已安装到
/lib/modules/$(uname -r)/目录下 - 是否漏执行
depmod -a更新依赖数据库 - 导出模块是否用了
EXPORT_SYMBOL_GPL，而依赖模块的MODULE_LICENSE不是 GPL 兼容许可证
真正容易被忽略的是：符号导出和模块安装是两件事。你写了 EXPORT_SYMBOL，但没把模块 .ko 放进 /lib/modules/ 并运行 depmod -a，modprobe 就永远找不到它。
