I tried to redo the code of the kernel module found in this topic How can I obtain battery level inside a Linux kernel module?. But when I try to use the functions contained in the power_supply.h header file, the loading of the module fails because it does not recognize the power_supply_get_by_name function.
Here is the code that I am using on Ubuntu 18.04 with kernel version 4.15.0-101-generic:
#include <linux/module.h>
#include <linux/power_supply.h>
static int __init test_init (void)
{
struct power_supply *psy;
char name[] = "BAT1";
psy = power_supply_get_by_name(name);
printk(KERN_DEBUG "Test module inserted");
return 0;
}
static void __exit test_exit (void)
{
printk(KERN_DEBUG "Test module removed");
}
module_init (test_init);
module_exit (test_exit);
I get no error at compiling except a warning concerning the module license which is I think not related to my problem but I get the following errors:
when running insmod in the terminal: "insmod: ERROR: could not insert module test.ko: Unknown symbol in module"
in the /var/log/kern.log file: "test: Unknown symbol power_supply_get_by_name (err 0)"
I checked the kallsyms proc file and the function is indicated as usable in other kernel modules if I understood well this topic What is the difference between T and t in /proc/kallsyms. Here is the output from reading the kallsyms file:
ffffffff8e9bd270 T power_supply_get_by_name
Does anyone knows why this is not working while I can use other linux headers functions without any problem and, if so, how I can fix my problem?
Thanks in advance
This may actually be related to the module license! If you look at the kernel source code, the function power_supply_get_by_name is exported here. You can see it's using EXPORT_SYMBOL_GPL. As this answer explains:
EXPORT_SYMBOL_GPL will show the symbol only in GPL-licensed modules
The use of this macro is controversial, but that's the way the project operates... To gain access to the symbols you need, you'll need to license your module as GPL:
MODULE_LICENSE("GPL");
Related
For examples, in pgtable_types.h, the function prototype:
extern pte_t *lookup_address(unsigned long address, unsigned int *level);
Is clearly present in the header file.
However when I compile a kernel module with this function and then insmod the .ko output file I get a lookup_address symbol not found error.
Why is this?
Does your module have a MODULE_LICENSE("GPL v2") line in it? If not, it is assumed to be proprietary and will not allow access to GPL symbols which lookup_address is marked as.
Everywhere I search for Linux Kernel Development, I get answers for creating Linux Kernel modules.
Example
/*
* hello−1.c − The simplest kernel module.
*/
#include <linux/module.h> /* Needed by all modules */
#include <linux/kernel.h> /* Needed for KERN_INFO */
int init_module(void)
{
printk(KERN_INFO "Hello world 1.\n");
/*
* A non 0 return means init_module failed; module can't be loaded.
*/
return 0;
}
void cleanup_module(void)
{
printk(KERN_INFO "Goodbye world 1.\n");
}
Here, there is init_module and cleanup_module functions which i understand contains things to be executed when the kernel is initialized and cleaned up.
There are made by adding
obj-m += hello-1.c
to the makefile.
But I dont want this. I want to add a built in program, not a driver, basically a service to facilitate cloud uploading of some data from the kernel level. I dont event want the module option for the program when compiling the kernel.
I understand for just programs I should use obj-y not obj-m. But there is no manual to write these kind of programs. Why? Am I missing something? Does these programs also have the init_module and cleanup_module functions even though they are not modules?
For example consider that your source is under driver/new in the linux kernel source tree.
You need to modify Makefile's under drivers and new to build your module statically into linux kernel.
Under drivers/Makefile add the below line at the end.
obj-y += new/
Under drivers/new/Makefile add the below line at the end.
obj-y += hello.o
After build the linux kernel. And load to see that your module has printed the printk messages using dmesg command.
Note: When building module statically into linux, change
int init_module(void)
to
int __init init_module(void)
and change
void cleanup_module(void)
to
void __exit cleanup_module(void)
Look into kernel doc Makefiles
Refer:
"
--- 3.2 Built-in object goals - obj-y
The kbuild Makefile specifies object files for vmlinux
in the $(obj-y) lists. These lists depend on the kernel
configuration.
Kbuild compiles all the $(obj-y) files. It then calls
"$(LD) -r" to merge these files into one built-in.o file.
built-in.o is later linked into vmlinux by the parent Makefile.
The order of files in $(obj-y) is significant. Duplicates in
the lists are allowed: the first instance will be linked into
built-in.o and succeeding instances will be ignored.
Link order is significant, because certain functions
(module_init() / __initcall) will be called during boot in the
order they appear. So keep in mind that changing the link
order may e.g. change the order in which your SCSI
controllers are detected, and thus your disks are renumbered.
Example:
#drivers/isdn/i4l/Makefile
# Makefile for the kernel ISDN subsystem and device drivers.
# Each configuration option enables a list of files.
obj-$(CONFIG_ISDN_I4L) += isdn.o
obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
"
I'm trying to call two exported (maybe) kernel functions from the KVM - kvm_write_guest and kvm_get_segment but when I compile a kernel driver that will call these two functions I get a warning saying they are undefined.
WARNING: "kvm_write_guest" [/home/driver.ko] undefined!
WARNING: "kvm_get_segment" [/home/driver.ko] undefined!
When I executed the commands:
cat /proc/kallsyms | grep kvm_get_segment
cat /proc/kallsyms | grep kvm_write_guest
to check to see if they are exported I get the following:
0000000000000000 t kvm_write_guest [kvm]
0000000000000000 t kvm_get_segment [kvm]
Below are the protocols and includes that I have in the header file that is included in the .c file that calls these functions. I pulled the prototypes from the kvm_main.c code.
#include <linux/kvm.h>
#include <linux/kvm_types.h>
#include <linux/kvm_host.h>
int kvm_write_guest(struct kvm *kvm, gpa_t gpa, const void *data, unsigned long len);
void kvm_get_segment(struct kvm_vcpu *vcpu, struct kvm_segment *var, int seg);
When I dig into the kvm_main.c source code for kvm_write_guest they don't seem to be exported using the following code:
EXPORT_SYMBOL_GPL(kvm_write_guest);
When I dig into the x86.c code for kvm_get_segment it isn't exported using that method either. It doesn't seem that they are in fact exported but I want to make sure I'm not doing something wrong. I'd like to avoid patching the code and recompiling if I can. Thank in advance for any help it is greatly appreciated!
You're not doing anything wrong. If they're not exported with EXPORT_SYMBOL or EXPORT_SYMBOL_GPL, you won't be able to call them from a module.
Looks like you have two different problems. kvm_get_segment is only defined in arch/x86/kvm/x86.c and is not exported. So another module can't link to it (without patching the source or playing complicated tricks at runtime).
On the other hand, as you point out, kvm_write-guest is exported, with:
EXPORT_SYMBOL_GPL(kvm_write_guest);
That means only GPL-licensed modules can link to it; you'll need to put
MODULE_LICENSE("GPL");
in your driver to use that symbol. (And make sure you understand the legal implications of doing that)
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?
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.
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?
OK: You have one module where the function is and one place what wants to import it right?
You must use "EXPORT_SYMBOL("name of the function") such as foo in the place where the function is. So in the "c" file have the function "foo" defined and put in:
EXPORT_SYMBOL(foo)
Make sure you have the prototype for "foo" in a common header file (you can have it in separate places for each module and it will work but you are asking for trouble if the signatures change). So say: void foo(void *arg);
Then the other module that wants it just invoke "foo" and you are good.
Also: Make sure that you load the module with foo first. If you have cross dependencies like module2 needs foo from module1 and module1 needs bar from module2 you need to have one register functions with another. If you want to know please ask a separate Q.
I'm embedding some driver into a Linux kernel when I get this error (I'm adding the device in the board file and registering it):
error: 'kxtf9_get_slave_descr' undeclared here (not in a function)
I located the function above in a driver file
struct ext_slave_descr *kxtf9_get_slave_descr(void)
{
return &kxtf9_descr;
}
EXPORT_SYMBOL(kxtf9_get_slave_descr);
Shouldn't it made "visible" by EXPORT_SYMBOL?
The C file containing the code above has no header file (I didn't write it, I just found it here and I'm implementing. They say it's tested so I assume an header is not needed?
The rest of the code compiles perfectly (so it "sees" the code in the folder), and the file containing the code above compiles as well!
EXPORT_SYMBOL exports the symbol for dynamic linking. What you have is not a linking error but a compilation error due to a missing function declaration. You have to either write a header file for the C file and include that header file, or you declare the function the C file you're compiling.
Option 1:
kxtf9.h:
#ifndef KXTF9_H
#define KXTF9_H
struct ext_slave_descr *kxtf9_get_slave_descr(void);
#endif
your_file.c:
#include "kxtf9.h"
/* your code where you use the function ... */
Option 2:
your_file.c:
struct ext_slave_descr *kxtf9_get_slave_descr(void);
/* your code where you use the function ... */
Also note that the EXPORT_SYMBOL in the file kxtf9.c has #ifdef __KERNEL__ around it, so you have to have set up your build environment (Makefile) correctly - otherwise you'll get a link error.