警告构建使用导出符号的内核模块 [英] Warning building a kernel module that uses exported symbols

问题描述

我有两个内核模块(例如modA和modB). modA使用EXPORT_SYMBOL(symA)导出符号，而modB使用它.我有modA的标题modA.h:

I have two kernel modules (say modA and modB). modA exports a symbol with EXPORT_SYMBOL(symA) and modB uses it. I have the header modA.h for modA:

...
extern void symA(int param);
...

和modB.c中的

#include "modA.h"
...
static int __init modB_init(void)
{
    symA(10);
}
...

如果我的insmod modB一切正常，则我的modB在内核中正确链接，并且函数symA被正确调用.但是，当我构建modB时，编译器会发出警告:symA is undefined. LKM是可重定位的ELF，那么为什么编译器会发出此警告?如何将其删除?

If i insmod modB all works fine, my modB is correctly linked in the kernel and the function symA is correctly called. However when i build modB the compiler raises a warning: symA is undefined. An LKM is an ELF relocatable so why the compiler raises this warning? How can be this removed?

推荐答案

此问题(以及在这种情况下如何正确编译)在http://www.kernel.org/doc/Documentation/kbuild/modules.txt

This issue (and how to compile correctly in this case) is explained in http://www.kernel.org/doc/Documentation/kbuild/modules.txt

有时，外部模块使用从另一个模块导出的符号 外部模块. kbuild需要全面了解所有符号 避免吐出有关未定义符号的警告.三 存在针对这种情况的解决方案.

Sometimes, an external module uses exported symbols from another external module. kbuild needs to have full knowledge of all symbols to avoid spitting out warnings about undefined symbols. Three solutions exist for this situation.

注意:建议使用具有顶级kbuild文件的方法，但可能会 在某些情况下不切实际.

NOTE: The method with a top-level kbuild file is recommended but may be impractical in certain situations.

使用顶级kbuild文件如果您有两个模块，则foo.ko和 bar.ko，其中foo.ko需要来自bar.ko的符号，您可以使用 通用顶级kbuild文件，因此两个模块都在 相同的版本.请考虑以下目录布局:

Use a top-level kbuild file If you have two modules, foo.ko and bar.ko, where foo.ko needs symbols from bar.ko, you can use a common top-level kbuild file so both modules are compiled in the same build. Consider the following directory layout:

  ./foo/ <= contains foo.ko       ./bar/ <= contains bar.ko

  The top-level kbuild file would then look like:

  #./Kbuild (or ./Makefile):          obj-y := foo/ bar/

  And executing

      $ make -C $KDIR M=$PWD

  will then do the expected and compile both modules with         full

任何一个模块中的符号知识.

knowledge of symbols from either module.

使用额外的Module.symvers文件构建外部模块后， 生成一个Module.symvers文件，其中包含所有导出的符号 在内核中没有定义.从以下位置访问符号 bar.ko，从bar.ko的编译中复制Module.symvers文件 到构建foo.ko的目录.在模块构建过程中， kbuild将读取目录中的Module.symvers文件. 外部模块，构建完成后， 创建包含所有符号之和的Module.symvers文件 定义，而不是内核的一部分.

Use an extra Module.symvers file When an external module is built, a Module.symvers file is generated containing all exported symbols which are not defined in the kernel. To get access to symbols from bar.ko, copy the Module.symvers file from the compilation of bar.ko to the directory where foo.ko is built. During the module build, kbuild will read the Module.symvers file in the directory of the external module, and when the build is finished, a new Module.symvers file is created containing the sum of all symbols defined and not part of the kernel.

使用"make"变量KBUILD_EXTRA_SYMBOLS如果不切实际， 从另一个模块复制Module.symvers，可以分配一个空格 在构建文件中将文件列表分隔为KBUILD_EXTRA_SYMBOLS. 这些文件将在初始化过程中由modpost加载. 其符号表.

Use "make" variable KBUILD_EXTRA_SYMBOLS If it is impractical to copy Module.symvers from another module, you can assign a space separated list of files to KBUILD_EXTRA_SYMBOLS in your build file. These files will be loaded by modpost during the initialization of its symbol tables.

这篇关于警告构建使用导出符号的内核模块的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！