内核之间的Linux内核模块(* .ko)兼容性 [英] Linux Kernel Module (*.ko) compatibility between kernels

查看:372
本文介绍了内核之间的Linux内核模块(* .ko)兼容性的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

I have a simple kernel object that I built for probing around at kernel memory.

如果我在64位Ubuntu(3.2)计算机上构建它,则在该计算机上可以正常工作.但这在我的64位Ubuntu(3.9)计算机上不会显示insmod.反之亦然.如果我尝试在非内核版本上运行它,则出现"-1无效的模块格式"错误.

If I build it on my 64-bit Ubuntu (3.2) machine it works fine on that machine. But it won't insmod on my 64-bit Ubuntu (3.9) machine. And vice versa. It gives me a "-1 Invalid module format" error if I try to run it on a Kernel rev other than the one I'd built it on.

我认为insmod将其动态链接到导出的符号表,并且导出的符号表在内核版本之间不会更改. (它被附加.)

I thought insmod linked it dynamically against the exported symbol table and the exported symbol table does not change between kernel revisions. (It gets appended.)

有人可以告诉我如何构建与将来(或过去)Linux内核兼容的内核模块(.ko),而不必在该内核上进行重建吗?

Can someone tell me how I can build a kernel module (.ko) that is compatible with future (or past) Linux kernels without having to be rebuilt on that kernel?

这是我的制作文件:

ccflags-y = -g

ccflags-y = -g

obj-m + = access_mem.o

obj-m += access_mem.o

全部: 制作-C/lib/modules/$(shell uname -r)/build M = $(PWD)模块

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

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

clean: 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或函数签名: ioctl签名已从内核版本2.3.36更改,因此您的代码应该如下所示

Joe, Ubuntu (3.2) maybe using kernel version x.y.z but Ubuntu (3.9) maybe using kernel version x.y.z1. If kernel versions differ you must need to build/compile your driver against that particular kernel version. If the kernel versions are same then no need to build your driver. Important point is that every driver module is been compiled or built linking with version.ko module (which actually embeds the information about the kernel version the driver module built against), while loading kernel module it checks for this information and kernel version, if different then throws "-1 Invalid module format" or if matched then kernel module is loaded successfully. To develop kernel module which is future or backward compatible you need to know on which kernel version which API's or functions signature have been changed for ex: ioctl signature changed from kernel version 2.3.36 onwards, so your code should be as below

#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 

如果以这种方式开发,则您的内核模块是将来或向后兼容的. 兼容性仅是对API或函数签名等的适应.通过在内核模块中保留较旧的API或函数签名等,可以针对内核版本进行更改.如上例所示,但仍然需要构建/编译您的内核内核模块与您尝试加载的内核版本相对应.

If developed in such a way then your kernel module is future or backward compatible. Compatibility is only adaptation of API's or function signature etc.. changes for the kernel version by preserving the older API's or function signature etc.. in your kernel module as in the above example, but still you need to build/compile your kernel module against the kernel version on which you are trying to load.

这篇关于内核之间的Linux内核模块(* .ko)兼容性的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆