kernel-module - 内核之间的 Linux 内核模块 (*.ko) 兼容性

Question

我有一个简单的内核对象，用于在内核内存中进行探测。

如果我在我的 64 位 Ubuntu (3.2) 机器上构建它，它可以在该机器上正常工作。但它不会在我的 64 位 Ubuntu (3.9) 机器上安装。反之亦然。如果我尝试在我构建它的内核版本之外的内核版本上运行它，它会给我一个“-1 无效的模块格式”错误。

我认为 insmod 将它与导出的符号表动态链接，并且导出的符号表在内核版本之间不会改变。 (它被附加了。)

有人能告诉我如何构建与 future (或过去)Linux 内核兼容的内核模块(.ko)，而无需在该内核上重新构建吗？

这是我的制作文件:

ccflags-y = -g

obj-m += access_mem.o

全部:
make -C/lib/modules/$(shell uname -r)/build M=$(PWD) modules

干净的:
make -C/lib/modules/$(shell uname -r)/build M=$(PWD) clean

Answer 1

Joe，Ubuntu (3.2) 可能使用内核版本 x.y.z，但 Ubuntu (3.9) 可能使用内核版本 x.y.z1。如果内核版本不同，您必须需要针对该特定内核版本构建/编译您的驱动程序。如果内核版本相同，则无需构建驱动程序。重要的一点是，每个驱动程序模块都被编译或构建与 version.ko 模块链接(实际上嵌入了有关驱动程序模块构建的内核版本的信息)，在加载内核模块时，它会检查此信息和内核版本，如果不同然后抛出 “-1 无效的模块格式” 或者如果匹配，则内核模块加载成功。要开发 future 或向后兼容的内核模块，您需要知道哪个内核版本的 API 或函数签名已更改，例如: ioctl 签名从内核版本 2.3.36 开始更改 ，所以你的代码应该如下

#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36)
static long minor_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
#else
static int minor_ioctl(struct inode *inode, struct file *filp, unsigned int cmd,  
                                                               unsigned long arg)
#endif 

如果以这种方式开发，那么您的内核模块是 future 或向后兼容的。 兼容性仅适用于 API 或函数签名等。通过在内核模块中保留旧 API 或函数签名等来更改内核版本，如上例所示，但您仍然需要构建/编译内核模块您尝试加载的内核版本。