linux内核自己添加模块（内核版本：3.0.101）

　　做内核驱动第一步都是学习如何添加模块，这是基础，有了这个基础，剩下就是写代码了。

　　由于2.4到2.6内核版本的更新，无论是系统调用还是模块添加机制都有了巨大的变化，本人也因此饱经挫折，最后在3.0.101版本的内核下成功。作为开源运动的支持者，自认为有必要把自己的经历分享出来，以供后来学习者分享与交流。

      再次声明，本博客只分享我遇到了的问题，没有交流的不代表不难或者不会遇到问题，只是我没遇到，如果有阅读本博客的朋友遇到了问题，非常欢迎大家一起讨论，技术就是这么成长的！

　　关于添加模块，步骤上还是那三步。

　　1.编写模块函数

　　编写内核模块时必须要有的两个函数 :

　　1> 加载 函数：

　　static int func1_init(void)

　　2> 卸载函数 无返回值

　　static void func2_exit(void)

　　这里值得注意的是三点，一是卸载函数必须是void，即无返回型，否则会报错。其二是推荐把加载函数改写成static int __init func1_init(void),卸载函数同理。这里使用__init是利用2.6内核以后的宏机制，具体机制。。。还在学习中。第三点就是人尽皆知的，加载函数的名字必须写成*_init的样子，卸载函数必须是*_exit的样子。

　

　　2.其次就是Makefile了。

　　这方面的文章比较多，网上也讲得非常详细，我就大概讲一下模板和每步的意义。

　　

obj-m := hello.o

kernel_path=/usr/src/linux-headers-$(shell uname -r)

all:

make -C $(kernel_path) M=$(PWD) modules

clean:

make -C $(kernel_path) M=$(PWD) clean

obj -m:= hello.o // 产生 hello 模块的目标

kernel_path // 定义内核源文件目录

all ：

make -C $(kernel_path) M=$(PWD) modules

// 生成内核模块参数为内核源代码目录以及模块所在目录

clean:

make -C $(kernel_path) M=$(PWD) clean

// 清除生成的模块文件以及中间文件

 

 

这里就要尤为注意了，在2.6版本以后，引入了如下机制。2.6中模块的编译需要配置过的内核源码；编译、连接后生成的内核模块后缀为.ko；编译过程首先会到内核源码目录下，读取顶层的Makefile文件，然后再返回模块源码所在目录。

接下来要讲得就是最折磨人的改变了。

2.4内核下， 执行`cat /proc/ksyms`可看到内核符号在名字后还跟随着一串校验字符串，此校验字符串与内核版本有关。在内核源码头文件linux/modules 目录下存在许多*.ver文件，这些文件起着为内核符号添加校验后缀的作用，如ksyms.ver 文件里有一行 #define printk _set_ver(printk)。linux/modversions.h 文件会包含全部的 ver文件 。所以当模块包含linux/modversions.h文件后，编译时，模块里使用的内核符号实质是带有校验后缀的内核符号。在加载模块时，如果模块中所使用内核符号的校验字符串与当前运行内核所导出的相应的内核符号的校验字符串不一致，即当前内核空间并不存在模块所使用的内核符号，就会出现"Invalid module format "的错误。

为内核符号添加校验字符串来验证模块的版本与内核的版本是否匹配是繁杂和浪费内核空间的；而且随着SMP（对称多处理器）、PREEMPT（可抢占内核）等机制在2.6内核的引入和完善，模块运行时对内核的依赖不仅取决于内核版本，还取决于内核的配置，此时内核符号的校验码是否一致不能成为判断模块可否被加载的充分条件。2.6 内核下，在linux/vermagic.h中定义有VERMAGIC_STRING，VERMAGIC_STRING不仅包含内核版本号，还包含有内核使用的gcc版本，SMP与PREEMPT等配置信息。模块在编译时，我们可以看到屏幕上会显示"MODPOST"。在此阶段， VERMAGIC_STRING会添加到模块的modinfo段。 在内核源码目录下scripts/mod/modpost.c文件中可以看到模块后续处理部分的代码。模块编译生成后，通过`modinfo mymodule.ko`命令可以查看此模块的vermagic等信息。2.6 内核下的模块装载器里保存有内核的版本信息，在装载模块时，装载器会比较所保存的内核vermagic与此模块的modinfo段里保存的vermagic信息是否一致，两者一致时，模块才能被装载。譬如Fedora core 4 与core 2 使用的都是2.6 版本内核， 在Fedore Core 2下去加载Fedora Core4下编译生成的hello.ko，会出现"invalid module format" 错误。

因此，细心的朋友注意到我给出的Makefile模板中编译目标是内核源码树。这里必须是这样，否则会出错。而且必须对应，即，如果你当前内核版本是3.0.101，就必须是以3.0.101的内核源码树为目标进行编译得到*.ko，否则会报错。反之亦然。两者必须一一对应，这一点希望朋友们务必注意，否则会痛不欲生。

以上就是我学习这部分最痛苦最值得分享的部分了，希望可以帮到大家。

由于2.6下各位朋友肯定希望自己的模块能兼容2.4下的模式，所以，我这里再提供一套Makefile，有IBM官方给出，值得学习。

# Makefile2.6
ifneq ($(KERNELRELEASE),)
#kbuild syntax. dependency relationshsip of files and target modules are listed here.
mymodule-objs := file1.o file2.o
obj-m := mymodule.o 
else
PWD  := $(shell pwd)
KVER ?= $(shell uname -r)
KDIR := /lib/modules/$(KVER)/build
all:
	$(MAKE) -C $(KDIR) M=$(PWD) 
clean:
rm -rf .*.cmd *.o *.mod.c *.ko .tmp_versions
endif