Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to call exported kernel module functions from another module?

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.

Notes:

  • 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?


EDIT: I found some information about this here: http://www.kernel.org/doc/Documentation/kbuild/modules.txt

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.

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

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.

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.

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.

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?

like image 549
jacobsowles Avatar asked Sep 07 '12 04:09

jacobsowles


People also ask

What is Export_symbol in Linux kernel?

EXPORT_SYMBOL() is a macro the Linux kernel headers define. It has not much in common with extern. It tells the kbuild mechanism that the symbol referred to should be part of the global list of kernel symbols. That, in turn allows kernel modules to access them.

How are kernel modules linked?

A user can link a module into the running kernel by executing the insmod external program. This program performs the following operations: Reads from the command line the name of the module to be linked. Locates the file containing the module's object code in the system directory tree.

What is Kbuild in kernel?

"kbuild" is the build system used by the Linux kernel. Modules must use kbuild to stay compatible with changes in the build infrastructure and to pick up the right flags to "gcc." Functionality for building modules both in-tree and out-of-tree is provided.


2 Answers

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.

like image 120
jacobsowles Avatar answered Oct 07 '22 01:10

jacobsowles


Minimal QEMU + Buildroot example

I have tested the following in a fully reproducible QEMU + Buildroot environment, so maybe having this working version version will help you find out what is wong with your code.

GitHub upstream is centered on the files:

  • dep.c
  • dep2.c
  • Makefile

dep.c

#include <linux/delay.h> /* usleep_range */ #include <linux/kernel.h> #include <linux/kthread.h> #include <linux/module.h>  MODULE_LICENSE("GPL");  int lkmc_dep = 0; EXPORT_SYMBOL(lkmc_dep); static struct task_struct *kthread;  static int work_func(void *data) {     while (!kthread_should_stop()) {         printk(KERN_INFO "%d\n", lkmc_dep);         usleep_range(1000000, 1000001);     }     return 0; }  static int myinit(void) {     kthread = kthread_create(work_func, NULL, "mykthread");     wake_up_process(kthread);     return 0; }  static void myexit(void) {     kthread_stop(kthread); }  module_init(myinit) module_exit(myexit) 

dep2.c

#include <linux/delay.h> /* usleep_range */ #include <linux/kernel.h> #include <linux/kthread.h> #include <linux/module.h>  MODULE_LICENSE("GPL");  extern int lkmc_dep; static struct task_struct *kthread;  static int work_func(void *data) {     while (!kthread_should_stop()) {         usleep_range(1000000, 1000001);         lkmc_dep++;     }     return 0; }  static int myinit(void) {     kthread = kthread_create(work_func, NULL, "mykthread");     wake_up_process(kthread);     return 0; }  static void myexit(void) {     kthread_stop(kthread); }  module_init(myinit) module_exit(myexit) 

And now you can do:

insmod dep.ko insmod dep2.ko 

With that Buildroot setup, things are already configuring depmod /lib/module/*/depmod with the dependency, so just this is enough to load both:

modprobe dep 

Also, if you built your kernel with CONFIG_KALLSYMS_ALL=y, then the exported symbol can be seen with:

grep lkmc_dep /proc/kallsyms 

see also: Does kallsyms have all the symbol of kernel functions?