EXPORT_SYMBOL和EXPORT_SYMBOL_GPL使用

在Linux内核模块开发中，`EXPORT_SYMBOL` 和 `EXPORT_SYMBOL_GPL` 是用于将函数或变量符号导出给其他模块使用的宏。它们的主要区别在于使用权限和适用范围。 ### 1. 功能与可见性 - `EXPORT_SYMBOL` 将符号导出为...

<think>好的，我现在需要解决用户遇到的modpost错误，也就是GPL不兼容模块gw5a_copy.ko使用了GPL-only符号'platform_driver_unregister'的问题。首先，我得回忆一下Linux内核模块的许可证相关机制。 根据用户提供的引用[1]，出现类似错误是因为模块的许可证声明不符合GPL，而内核中的某些符号（比如这里的platform_driver_unregister）被标记为GPL-only，只有声明为GPL兼容的模块才能使用这些符号。因此，我需要检查模块的许可证声明是否正确。 接下来，用户提供的引用[4]提到，高版本内核中接口有变化，可能需要调整代码。这里可能需要确认platform_driver_unregister的使用是否符合当前内核版本的要求，比如函数原型或相关结构体是否有变化。不过，许可证问题更可能是主要原因。 然后，解决方案方面，第一步应该是修改模块的许可证声明。通常在模块代码的最后会有MODULE_LICENSE("...")的宏，需要将其改为"GPL"或者兼容的许可证，如"GPL v2"等。这样modpost在检查时就会允许模块使用GPL-only的符号。 如果用户确实不能将模块改为GPL许可证，可能需要寻找替代函数或重构代码，避免直接调用GPL-only的符号。但根据引用[4]中的情况，高版本内核可能已经移除了非GPL的替代接口，所以这条路可能行不通，只能调整许可证声明。 另外，检查Makefile是否正确，确保编译时使用的内核源码路径正确，如引用[3]中的KERN_DIR设置是否正确。虽然这可能不是导致许可证错误的原因，但确保编译环境正确有助于排除其他潜在问题。 最后，用户可能需要重新编译并安装模块，测试是否解决了问题。如果仍然出现错误，可能需要进一步审查代码中是否有其他依赖GPL-only符号的地方，或者内核版本升级带来的其他接口变化。</think>### 解决方案：GPL不兼容模块使用GPL-only符号错误 该错误是由于模块未声明为GPL兼容许可证，却调用了内核中标记为`EXPORT_SYMBOL_GPL()`的符号（如`platform_driver_unregister`）。以下是具体解决步骤： --- #### **步骤1：确认模块许可证声明** 在模块源代码（如`gw5a_copy.c`）末尾添加GPL许可证声明： ```c MODULE_LICENSE("GPL"); // 或 MODULE_LICENSE("GPL v2"); ``` *这是强制要求*，否则无法通过modpost检查[^1][^4]。 --- #### **步骤2：验证内核符号导出类型** 通过以下命令查看符号`platform_driver_unregister`的导出类型： ```bash grep platform_driver_unregister /proc/kallsyms ``` 若输出包含`GPL-only`标记，则必须使用GPL兼容许可证。 --- #### **步骤3：检查内核版本兼容性** 高版本内核（如4.19+）可能移除非GPL替代接口。若代码基于旧版内核（如2.6.32），需按新版API调整代码结构。 --- #### **步骤4：重编译并测试** 1. 清理编译环境： ```bash make clean ``` 2. 重新编译模块： ```bash make -C /path/to/kernel/source M=$(pwd) modules ``` 3. 加载模块验证： ```bash sudo insmod gw5a_copy.ko ``` --- #### **替代方案（不推荐）** 若无法声明GPL许可证，需重构代码： 1. 避免直接调用`platform_driver_unregister`，改用其他非GPL接口。 2. 重新设计驱动架构，减少对GPL符号的依赖。 ---