Marking loadable kernel module as in-tree
In short, the build system contrives to add the line MODULE_INFO(intree, "Y");
to the "modulename.mod.c" file if and only if the module is being built intree.
There is an obvious way to fool the system by adding that line to one of your module's regular ".c" files, but I'm not sure why you'd want to.
Longer version....
External modules are normally built with a command similar to this:
$ make M=`pwd` modules
or the old syntax:
$ make SUBDIRS=`pwd` modules
The presence of a non-empty M
or SUBDIRS
causes the kernel's top-level "Makefile" to set the KBUILD_EXTMOD
variable. It won't be set for a normal kernel build.
For stage 2 of module building (when the message "Building modules, stage 2" is output), make runs the "scripts/Makefile.modpost" makefile. That runs scripts/mod/modpost
with different options when KBUILD_EXTMOD
is set. In particular, the -I
option is used when KBUILD_EXTMOD
is set.
Looking at the source for modpost
in "scripts/mod/modpost.c", the external_module
variable has an initial value of 0, but the -I
option sets it to 1. The function add_intree_flag()
is called with the second parameter is_intree
set to !external_module
. The add_intree_flag()
function writes MODULE_INFO(intree, "Y");
to the "modulename.mod.c" file if and only if its is_intree
parameter is true.
So the difference between intree modules and external modules is the presence of the MODULE_INFO(intree, "Y");
macro call in the "modulename.mod.c" file. This gets compiled to "modulename.mod.o" and linked with the module's other object files to form the "modulename.ko" file.
Mr M.
Updated on June 03, 2022Comments
-
Mr M. almost 2 years
This question is about linux kernel 4.10.
Loading an out-of-tree LKM causes kernel to print a warning:
module: loading out-of-tree module taints kernel.
This raises from this check in module.c:
if (!get_modinfo(info, "intree")) {
Reading
get_modinfo
it seams that "intree" is just a a magic-string livnig inside the.ko
file.Running
readelf
on a random LKM I found in my system shows this:readelf -a imon.ko | grep intree 161: 00000000000006c0 9 OBJECT LOCAL DEFAULT 13 __UNIQUE_ID_intree1
While looking for
intree
in a simple, custom hello_world LKM returns no results.Is this actually the case?
How are some modules marked as being in-tree? Is it done by adding a macro to the module (like MODULE_LICENCE), or by building the module in a specific way or something else?
-
frr about 5 yearsAt a first look, this looks a little unfair to people writing perfectly open-source kernel code, but having to manage their drivers/modules out of tree. Only a few elite individuals enjoy the luxury of having their code actually in the vanilla tree. So as an "outsider", you can fudge that macro while staying out of tree, or you need to keep patching your local copy of the upstream vanilla tree. AFAIR, a tainted kernel is deprived of some debugging features...
-
frr about 5 yearsOR, THEN AGAIN, there is another way of looking at this: maybe the Linux leaders do want you to get used to the GIT. To maintain your own local branch, and instead of publishing a tarball, you ask an upstream maintainer to include your code, by sending a pull request...