3.执行命令insmod ./hello.ko插入模块,失败,错误信息是insmod: error inserting './hello.ko': -1 Invalid module format。
4.执行命令cat /var/log/message | tail,打印信息version magic '2.6.25.14 mod_unload 686' should be '2.6.25-14.fc9.i686 SMP mod_unload 686 4KSTACKS'。
5.通过命令看一下模块的相关信息
[lgw@localhost shareArm]$ sudo modinfo Dev_hello.ko [sudo] password for lgw: filename: depends: vermagic: |
6
参考信息1:
10.
可装入模块的编写者必须意识到,可装入模块既独立于内核又依赖于内核,所谓“独立”是因为它可以独立编译,所谓依赖是指它要调用内核或其他已装入模块的函数或变量,因此,内核版本的变化直接影响着曾经编写的模块是否能被新的内核认可。
例如,mydriver.o是基于Linux2.2.1内核编写和编译的,但是有人想把它装入到Linux2.2.2的内核中,如果mydriver.o所调用的内核函数在2.2.2中有所变化,那么内核怎么知道内核版本与模块所调用函数的版本不一致呢?
为了解决这个问题,可装入模块的开发者就决定给模块也编以内核的版本号。在上面的例子中,mydriver.o目标文件的.modinfo特殊区段就含有“2.2.1”,因为mydriver.o的编译使用了来自Linux 2.2.1的头文件,因此,当把该驱动程序装入到2.2.2内核时,insmod就会发现不匹配而失败,从而告诉你内核版本不匹配。
但是,Linux2.2.1
#define register_chrdev register_chrdev_Rc8dc8350
把符号register_chrdev定义为register_chrdev加上一个后缀,这个后缀就是register_chrdev()函数实际源代码的校验和,只要函数的源代码改动一个字符,这个校验和也会发生变化。因此,尽管你在源代码中读到的函数名为register_chrdev,但C的预处理程序知道真正调用的是register_chrdev_Rc8dc8350。