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

我有一个简单的内核对象,我为内核内存探测而构建.

如果我在我的64位Ubuntu(3.2)机器上构建它,它在该机器上工作正常.但它不会在我的64位Ubuntu(3.9)机器上进行insmod.反之亦然.如果我尝试在内核上运行它而不是我构建它的那个,它会给我一个“-1无效的模块格式”错误.

我认为insmod将动态链接到导出的符号表,导出的符号表在内核修订版之间不会发生变化. (它被附加.)

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

这是我的make文件：

ccflags-y = -g

obj-m = access_mem.o

所有：

make -C / lib / modules / $(shell uname -r)/ build M = $(PWD)模块

清洁：

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

@H_301_20@

Joe,Ubuntu(3.2)可能使用内核版本x.y.z但Ubuntu(3.9)可能使用内核版本x.y.z1.如果内核版本不同,则必须针对该特定内核版本构建/编译驱动程序.如果内核版本相同,则无需构建驱动程序.重要的一点是,每个驱动程序模块都已经编译或构建,与version.ko模块链接(实际上嵌入了驱动程序模块构建的内核版本的信息),而加载内核模块则会检查此信息和内核版本,如果不同然后抛出“-1无效的模块格式”或如果匹配则成功加载内核模块.要开发未来或向后兼容的内核模块,您需要知道哪个内核版本的API或函数签名已更改为ex：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 long arg)

#endif

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

@H_301_20@

@H_301_20@

总结

如果觉得编程之家网站内容还不错，欢迎将编程之家网站推荐给程序员好友。

本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。