I have this embedded Linux devices. I would like to add kernel-level functionality to it, but would highly prefer not to compile my own kernel to do so. (If the kernel doesn't load and get to user space the device is bricked; I can't access the bootloader to recover it. The current kernel doesn't have kexec support so I couldn't use that to test a kernel image of my own.)
The device's kernel has support for modules, but I do not have a copy of the corresponding Module.symvers file.
My question: if I do not have the Module.symvers file for a Linux kernel but do have the kernel image and a module compiled for it, can I compile more modules that can be inserted into that kernel, maybe by generating the missing Module.symvers file?
The device is running Linux kernel version 3.10.
Kernel image (in its uImage container): https://www.olio.watch/olio-firmware-1.10.220/olio-firmware/uImage
Configuration (extracted from above image thanks to CONFIG_IKCONFIG): https://www.olio.watch/3.10.0-g2ae2f33-config
The one kernel module I have that matches that kernel: https://www.olio.watch/olio-firmware-1.10.220/olio-firmware/drv2605.ko
Best Answer
First, in order to answer your question "can I compile Linux kernel module without Module.symvers", we need to understand what is the purpose of
Module.symvers
:Module.symvers
serves two main purposes:1) It lists all exported symbols from vmlinux and all modules.
2) It lists the CRC if
CONFIG_MODVERSIONS
is enabled. WithoutCONFIG_MODVERSIONS
enabled, the CRC would read 0x00000000.Module.symvers
will be generated during a kernel build, it contains all exported symbols from the kernel and compiled modules. For each symbol, the corresponding CRC value is also stored. The syntax of the Module.symvers file is:For example:
Having said that, if we have
Module.symvers
then we can build any module because it contain all the necessary symbols.If
Module.symvers
is not available, we still able to build an external module either by building this file or by borrowing it from another module.Usually, when building an external module, the build system needs access to the symbols from the kernel to check if all external symbols are defined. This is done in a build step called
MODPOST
. This step obtains the symbols by readingModule.symvers
from the kernel source tree.If a
Module.symvers
file is present in the directory where the external module is being built, this file will be read too. During theMODPOST
step, a newModule.symvers
file will be written containing all exported symbols that were not defined in the kernel.if
Module.symvers
file is not present, then an external module might be using an exported symbols from another external module,kbuild
needs to have full knowledge of all symbols to avoid spitting out warnings about undefined symbols.For this situation, there are three solutions:
1) Use a top-level
kbuild
file: If you have two modules,foo.ko
andbar.ko
, wherefoo.ko
needs symbols frombar.ko
, you can use a common top-levelkbuild
file so both modules are compiled in the same build. Consider the following directory layout:2) Use an extra
Module.symvers
file: When an external module is built, aModule.symvers
file is generated containing all exported symbols which are not defined in the kernel. To get access to symbols frombar.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 theModule.symvers
file in the directory of the external module, and when the build is finished, a newModule.symvers
file is created containing the sum of all symbols defined and not part of the kernel.3) Use "make" variable
KBUILD_EXTRA_SYMBOLS
: If it is impractical to copyModule.symvers
from another module, you can assign a space separated list of files toKBUILD_EXTRA_SYMBOLS
in your build file. These files will be loaded bymodpost
during the initialization of its symbol tables.More details 1