调用导出的内核模块的功能 [英] Calling exported kernel module functions

问题描述

我在写一个API作为一个内核模块，提供设备驱动程序的各种功能。我在我的code.C 写了三个功能。然后我建立并加载模块，然后复制我的code.h 到＆LT;内核> /在include / linux 。在设备驱动程序，我有一个的#include＆LT; Linux的/我的code.h> 并呼吁这三项功能。但是，当我建立了驱动模块，我得到三个链接器警告说，那些函数是未定义

I'm writing an API as a kernel module that provides device drivers with various functions. I wrote three functions in mycode.c. I then built and loaded the module, then copied mycode.h into < kernel >/include/linux. In a device driver, I have a #include < linux/mycode.h > and call those three functions. But when I build the driver module, I get three linker warnings saying that those functions are undefined.

注：

• 的函数声明的extern 在我的code.h


• 的功能是使用出口的 EXPORT_SYMBOL（FUNC_NAME）在我的code.C


• 运行命令NM我的code.ko显示所有三个功能在符号表是可用的（大写字母T旁边，这意味着符号在文中找到（code）第）


• 加载模块，命令的的grep FUNC_NAME的/ proc / kallsyms 后显示这三个功能被加载

• The functions are declared extern in mycode.h
• The functions are exported using EXPORT_SYMBOL(func_name) in mycode.c
• Running the command nm mycode.ko shows all three functions as being available in the symbol table (capital T next to them, meaning the symbols are found in the text (code) section)
• After loading the module, the command grep func_name /proc/kallsyms shows all three functions as being loaded

所以很明显的职能正在正确导出和内核知道他们在哪里。那么，为什么不能驾驶者看到自己的定义是什么？任何想法，我缺少什么？

So clearly the functions are being exported correctly and the kernel knows what and where they are. So why can't the driver see their definitions? Any idea what am I missing?

编辑：我发现这个了一些信息： 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.

使用制造变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.

但所有这三个解决方案，以任何驱动程序才能使用我的API，那就要创建一个新的Makefile或直接访问我的文件Module.symvers？这似乎有点不方便。我希望他们只希望能＃包括我的头文件是好去。难道没有其他方法存在？

But with all three of these solutions, in order for any driver to use my API, it would have to either create a new Makefile or have direct access to my Module.symvers file? That seems a bit inconvenient. I was hoping they'd just be able to #include my header file and be good to go. Do no other alternatives exist?

推荐答案

从我的研究，似乎只有这些三种方式来处理这种情况，我已经得到了他们每个人的工作，所以我想我会只挑我喜欢的淘汰者。

From my research, it seems that those are the only three ways to handle this situation, and I've gotten each of them to work, so I think I'll just pick my favorite out of those.

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