linux内核模块编译-通过Makefile重命名.ko文件名和模块名

假设模块的源文件为hello.c，源码如下：

使用该文件编译内核模块。

正常情况下，Makefile文件内容如下：

执行 make 命令，生成hello.ko文件。

执行 sudo insmod hello.ko 命令，安装该模块。

执行 lsmod 命令，查看安装的模块。就会看到第一行的就是hello模块。

但是，如果想自定义模块名称为 xmodule ，而不是默认的 hello ，如何实现呢？方法如下：

在Makefile中重命名obj-m并将obj-m的依赖关系设置为原始模块(hello)

修改后的Makefile文件内容如下：

将obj-m设置为 xmodule .o，并使 xmodule .o依赖于 hello .o.

执行 make 命令后，生成 xmodule .ko, 而不是 hello .ko，

安装命令: sudo insmod xmodule.ko

查看命令： lsmod ，就会看到被安装名为 xmodule 的模块。

一、.ko 文件介绍

.ko文件是kernel object文件（内核模块），该文件的意义就是把内核的一些功能移动到内核外边， 需要的时候插入内核，不需要时卸载。

二、优点

（1）这样可以缩小内核体积；

（2）使用方便。

三、.ko文件一般的用处

（1）作为一个功能模块，需要使用时，直接插入运行就行。如在imx6上连接模拟摄像头，先运行模拟摄像头对应的驱动模块 camera.ko文件，然后对应的工程执行文件运行就行。

四、使用.ko 文件

1、加载驱动模块test.ko

（1）方法一 

进入test.ko驱动模块文件所在的目录，然后直接   insmod  test.ko 

（2）方法二 

将test.ko文件拷贝到/lib/module/#uname-r#/目录下，这里，#uname -r#意思是，在终端中输入 

uname -r后显示的内核版本及名称，例如mini2440中#uname-r#就是2.6.32.2-FriendlyARM。

然后 depmod（会在/lib/modules/#uname -r#/目录下生成modules.dep和modules.dep.bb文件，表明模块的依赖关系） 

最后 modprobe test（注意这里无需输入.ko后缀） 即可

注：两种方法的区别

modprobe和insmod类似，都是用来动态加载驱动模块的，区别在于modprobe可以解决load module时的依赖关系，它是通过/lib/modules/#uname -r/modules.dep(.bb)文件来查找依赖关系的；而insmod不能解决依赖问题。也就是说，如果你确定你要加载的驱动模块不依赖其他驱动模块的话，既可以insmod也可以modprobe，当然insmod可以在任何目录下执行，更方便一些。而如果你要加载的驱动模块还依赖其他ko驱动模块的话，就只能将模块拷贝到上述的特定目录，depmod后再modprobe。

首先，我们要了解一下模块是如何别被构造的。模块的构造过程与用户空间

的应用程序的构造过程有显著不同；内核是一个大的、独立的程序

,

对于它的各

个部分如何组合在一起有详细的明确的要求。

Linux2.6

内核的构造过程也与以

前版本的内核构造过程不同；

新的构造系统用起来更加简单，

并且可产生更加正

确的结果

,

但是它看起来和先前的方法有很大不同。内核的构造系统非常复杂

,

我们所看到的只是它的一小部分。

如果读者想了解更深入的细节，

则应阅读在内

核源码中的

Document/kbuild

目录下的文件。

在构造内核模块之前，

有一些先决条件首先应该得到满足。

首先，

读者要保证你

有适合于你的内核版本的编译器、模块工具

,

以及其他必要工具。在内核文档目

录下的文件

Documentation/Changes

里列出了需要的工具版本；

在开始构造内

核前，

读者有必要查看该文件，

并确保已安装了正确的工具。

如果用错误的工具

版本来构造一个内核

(

及其模块

)

，可能导致许多奇怪的问题。另外也要注意

,

使

用太新版本的编译器偶尔可能也会导致问题。

一旦做好了上面的准备工作之后

,

其实给自己的模块创建一个

makefile

则非常

简单。实际上

,

对于本章前面展示的

" hello world"

例子

,

下面一行就够了

:

obj-m := hello.o

如果读者熟悉

make

，

但是对

Linux2.6

内核构造系统不熟悉的话

,

可能奇怪这个

makefile

如何工作。毕竟上面的这一行不是一个传统的

makefile

的样子。问

题的答案当然是内核构造系统处理了余下的工作。上面的赋值语句

(

它利用了由

GNU make

提供的扩展语法

)

说明有一个模块要从目标文件

hello.o

构造，而从

该目标文件构造的模块名称为

hello.ko.

如果我们想由两个源文件

(

比如

file1.c

和

file2.c )

构造出一个名称为

module.ko

的模块

,

则正确的

makefile

可如下编写

:

obj-m := module.o

module-objs := file1.o file2.o

为了让上面这种类型的

makefile

文件正常工作

,

必须在大的内核构造系统环境

中调用他们。假设读者的内核源码数位于

~/kernel-2.6

目录

,

用来建立你的模

块的

make

命令

(

在包含模块源代码和

makefile

的目录下键入

)

应该是

:

make -C ~/kernel-2.6 M=`pwd` modules

这个命令首先是改变目录到用

-C

选项指定的位置

(

即内核源代码目录

)

，其中保

存有内核的顶层

makefile

文件。这个

M=

选项使

makefile

在构造

modules

目

标前

,

返回到模块源码目录。

然后，

modules

目标指向

obj-m

变量中设定的模块，

在上面的例子里，我们将该变量设置成了

module.o

。

上面这样的

make

命令对于多个文件的编译显得不是很方便

,

于是内核开发者就

开发了一种

makefile

方式

,

这种方式使得内核树之外的模块构造变得更加容易。

代码清单

1.4

展示了

makefile

的编写方法：

代码清单

1.4 makefile

ifeq ($(KERNELRELEASE),)

KERNELDIR ?= /source/linux-2.6.13

PWD := $(shell pwd)

modules:

$(MAKE) -C $(KERNELDIR) M=$(PWD) modules

modules_install:

$(MAKE) -C $(KERNELDIR) M=$(PWD) modules_install

clean:

rm -rf *.o *~ core .depend .*. *.ko *.mod.c .tmp_versions

.PHONY: modules modules_install clean

else

obj-m := hello.o

endif

我们再次看到了扩展的

GNU

make

语法在起作用。在一个典型的构造过程中，这

个

makefile

将被读取两次。当从命令行中调用这个

makefile ,

它注意到

KERNELRELEASE

变量尚未设置。我们可以注意到，已安装的模块目录中存在一

个符号连接，

它指向内核的构造树，

这样这个

makefile

就可以定位内核的源代

码目录。如果读者时间运行的内核并不是要构造的内核，则可以在命令行提供

KERNELDIR=

选项或者设置

KERNELDIR

环境变量

,

或者修改

makefile

中设置

KERNELDIR

的那一行。在找到内核源码树

,

这个

makefile

会调用

default:

目

标

,

这个目标使用先前描述过的方法第二次运行

make

命令

(

注意，在这个

makefile

里

make

命令被参数化成

$(MAKE))

，以便运行内核构造系统。在第二

次读取

makefile

时，

它设置了

obj-m,

而内核的

makefile

负责真正构造模块。

这种构造模块的机制看起来很繁琐，可是，一旦我们习惯了使用这种机制

,

则会

欣赏内核构造系统带给我们的便利。需要注意的是

,

上面

makefile

并不完整，

一个真正的

makefile

应包含通常用来清除无用文件的目标

,

安装模块的目标等

等。一个完整的例子可以参考例子代码目录的

makefile

。

---