insmod一个ko提供基础函数供后insmod的ko使用的方法
一、背景
在内核模块开发时，多个不同的内核模块，有时候可能需要都共用一些公共的函数，比如申请一些平台性的公共资源。但是，这些公共的函数又不方便去加入到内核镜像里，这时候就需要把这些各个内核模块需要用到的一些公共的函数做到一个ko里，先insmod，这样后insmod的内核模块就可以使用这些公共的函数。
需求已经说清楚了，我们直接看代码。
二、内核模块公共api的需求实现的demo例子
我们创建一个moduleapitest文件夹来做这个demo，这个文件夹里有两个子文件夹，一个是apiko文件夹，是模拟实现公共api的一个ko（api.ko），在使用时早于其他的ko先insmod，还有一个是使用api.ko里函数的ko，我们叫useapi.ko，对应的目录叫useapiko。
下图中红色框出的是需要编写的文件：
先看一下apiko目录下的api.c和Makefile
#include <linux/module.h>
#include <linux/kernel.h>MODULE_LICENSE("GPL");
MODULE_AUTHOR("zhaoxin");
MODULE_DESCRIPTION("A simple Linux kernel module define api...");
MODULE_VERSION("1.0");void test_api_log(void) {printk(KERN_INFO "test_api_log output.\n");
}
EXPORT_SYMBOL_GPL(test_api_log);static int __init api_init(void) {printk(KERN_INFO "api_init: Module loaded.\n");return 0;
}static void __exit api_exit(void) {printk(KERN_INFO "api_exit: Module unloaded.\n");
}module_init(api_init);
module_exit(api_exit);
上图中可以看到，我们定义了一个api叫test_api_log，里面进行了一句打印，记得要EXPORT_SYMBOL或者EXPORT_SYMBOL_GPL一下
apiko里的Makefile文件如下：
obj-m += api.oall:make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modulesclean:make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean在编译时，这个提供api的ko需要先进行编译，因为编译生成的Module.symvers我们需要用：
关键是看useapi怎么才能使用到这个symbol：
useapi.c的源文件：
#include <linux/module.h>
#include <linux/kernel.h>MODULE_LICENSE("GPL");
MODULE_AUTHOR("zhaoxin");
MODULE_DESCRIPTION("A simple Linux kernel module using api...");
MODULE_VERSION("1.0");extern void test_api_log(void);static int __init useapi_init(void) {test_api_log();printk(KERN_INFO "useapi_init: Module loaded.\n");return 0;
}static void __exit useapi_exit(void) {printk(KERN_INFO "useapi_exit: Module unloaded.\n");
}module_init(useapi_init);
module_exit(useapi_exit);
可以看到useapi.c源文件里的初始化函数里使用了test_api_log：
再看一下useapi的Makefile，也就是这个功能的核心：
obj-m += useapi.oTEST_DIR = $(CURDIR)/../KBUILD_EXTRA_SYMBOLS = $(TEST_DIR)/apiko/Module.symvers
export KBUILD_EXTRA_SYMBOLSall:make -C /lib/modules/$(shell uname -r)/build M=$(PWD) TEST_DIR=$(TEST_DIR) modulesclean:make -C /lib/modules/$(shell uname -r)/build M=$(PWD) TEST_DIR=$(TEST_DIR) clean上面Makefile里有两处关键：
1）定义KBUILD_EXTRA_SYMBOLS为提供公共api的编译产出物Module.symvers
2）注意目录如果要用当前目录这个Makefile的内置变量（$(CURDIR)）的话，得多用一个变量来使用它（上面例子里就是TEST_DIR），然后再把TEST_DIR传给make的编译语句：
否则，Makefile在执行时，$(CURDIR)会被解释成-C后面的目录所指向的路径：
而/home/zhaoxin/code/git/los/code/test/linux-6.5这个目录作为$(CURDIR)的话，就和你在写Makefile时认为的当前目录不一致了造成找不到这个Module.symvers的编译错误
另外，如果遇到如下的编译错误：
大概率是因为，你没有把公共函数的api进行EXPORT_SYMBOL
实验验证：
如果不先insmod api.ko的话，直接insmod useapi.ko的话，会出现如下错误：
这也是符合预期，因为这个symbol依赖api.ko的插入才存在。
下面是先insmod api.ko再insmod useapi.ko的dmesg输出：
可以看到useapi.ko能使用api.ko里的EXPORT_SYMBOL的符号
三、有哪些应用场景？
我们可以定义一些内核模块统一用到的一些日志函数，当然可以使用原生的printk，但是有时候还是使用自己写的东西拓展功能起来方便一些。比如我们可以定义一些模式，全局一块大buffer，还是分线程独立的buffer，还是分进程独立的buffer，还是按照模块独立的buffer，这些需求用自己写的一套公共的api来给各个内核模块调用，后续日志的功能改变后，各个内核模块也不用去修改各自的代码，我们可以迭代公共api的这个ko即可。
还比如说，我们可以定义一些公共的内存申请的函数和一些traceid跟踪的函数等等，可以想到进行抽象出来定义的api还有很多。