Linux内核模块间通信：EXPORT_SYMBOL与EXPORT_SYMBOL_GPL的实战解析

1. 内核模块通信的核心机制

当你开始设计一个由多个内核模块组成的复杂驱动时，模块间的函数调用和数据共享就成了必须面对的挑战。想象一下，你正在构建一个网络设备驱动，其中数据处理、硬件控制和协议栈需要分别由不同模块实现——这时候就需要一种可靠的"桥梁"来连接这些模块。在Linux内核中，EXPORT_SYMBOL和EXPORT_SYMBOL_GPL就是这样的桥梁建造工具。

我曾在开发一个存储设备驱动时深有体会：当把IO调度、缓存管理和设备控制拆分成三个独立模块后，发现调度模块需要直接调用缓存模块的统计函数。这时候如果重新合并代码就违背了模块化设计的初衷，而EXPORT_SYMBOL正好提供了完美的解决方案。通过在缓存模块中导出统计函数，调度模块就能像调用本地函数一样使用它，同时保持代码的松耦合。

这种机制背后的工作原理其实很有趣。当你在模块中使用EXPORT_SYMBOL(func)时，内核会把这个函数的地址和符号名记录在一个特殊的段（__ksymtab）中。其他模块加载时，内核的动态链接器会根据这个表完成函数地址的绑定。这就像是在模块间建立了一个电话簿——A模块说"我需要调用clean_cache函数"，内核就查表告诉它"这个函数在B模块的0xbf00d8c0地址"。

2. 两种导出方式的本质区别

第一次看到EXPORT_SYMBOL和EXPORT_SYMBOL_GPL时，我误以为它们只是命名风格不同。直到某次尝试在闭源模块中调用一个GPL-only的函数时，才真正理解它们的深层差异。那次insmod失败的错误信息让我记忆犹新："Unknown symbol in module"——明明符号表里有这个函数，为什么说找不到呢？

关键区别在于许可证检查机制。EXPORT_SYMBOL_GPL导出的符号会带有特殊的标记，当非GPL模块尝试调用时，内核会主动拒绝。你可以通过一个简单的实验验证这点：

c复制// gpl_module.c
#include <linux/module.h>
static void gpl_func(void) {
    printk("GPL function called\n");
}
EXPORT_SYMBOL_GPL(gpl_func);

MODULE_LICENSE("GPL");

// non_gp