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

本站教程收集整理的这篇文章主要介绍了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

所有：@H_97_15@make -C / lib / modules / $(sHell uname -r)/ build M = $(PWD)模块

清洁：@H_97_15@make -C / lib / modules / $(sHell uname -r)/ build M = $(PWD)clean

解决方法

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或函数签名等来改变内核版本,如上例所示,但仍然需要构建/编译内核模块您尝试加载的内核版本.

本站总结

以上是本站教程为你收集整理的kernel-module – 内核之间的Linux内核模块(* .ko)兼容性全部内容，希望文章能够帮你解决kernel-module – 内核之间的Linux内核模块(* .ko)兼容性所遇到的程序开发问题。

如果觉得本站教程网站内容还不错，欢迎将本站教程推荐给好友。

本图文内容来源于网友网络收集整理提供，作为vps云服务器学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。