配色: 字号:
转kbuild module
2013-04-07 | 阅:  转:  |  分享 
  
在这个文档里你可以找到以下信息:

-如何建立一个外部模块

-如何用kbuild结构来编译你的模块

-如何在非标准定位处安装你的模块



===内容表



===1简介

===2如何建立外部模块

---2.1建立外部模块

---2.2可用的目标

---2.3可用的选项

---2.4为建立模块准备的内核树

===3示例命令

===4为外部模块建一个kbuild文件

===5包含文件

---5.1如何包含内核include目录中的文件

---5.2外部模块使用include/目标

===6模块安装

---6.1INSTALLL_MOD_PATH

---6.2INSTALL_MOD_DIR

===7模块版本

===8提示和技巧

---8.1测试CONFIG_FOO_BAR



===1.简介



kbuild的功能包括内核源代码树的内部和外部的模块.稍后会经常提及到外部模块,它是用来在开发中使用的,而没有打算把它放到内核树中.



这个文件掩盖了模块作者的主要信息.外部模块的作者必须提供一个Makefile文件来隐藏复杂的细节,使别人只要输入"make"就可以编译这个模块.一个完整的例子将会在第4章描述:为外部模块创建一个kbuild文件".



===2.如何构建一个外部模块



kbuild具有利用完整代码预构建的内核变量来构建外部模块的功能.在构建外部模块的时候,一系列在构建内核有效时的目标变得有效.



---2.1构建外部模块



利用下面的命令来构建一个外部模块:

make-CM=`pwd`



如果用正在运行着的内核用:

make-C/lib/modules/`uname-r`/buildM=`pwd`

如果要使上面的命令成功执行,内核必须是编译成可以模块加载的.



安装模块可以用以下命令:

make-CM=`pwd`modules_install



上面只是个开头,后面有更复杂的例子.



---2.2有效的目标



$KDIR是内核源代码的根目录



make-C$KDIRM=`pwd`

将在当前目标下创建模块.所有的输出文件都在模块源代码的目录下生成.没有企图去更新内核源代码,同时它是对内核成功执行make的先决条件.



make-C$KDIRM=`pwd`modules

当没有指定目标时,模块目标是暗指的.它的功能是和没有指定特定目标是一样的,像上面描述的样.

make-C$KDIRM=$PWDmodiles_install

安装外部模块.

默认安装目录为/lib/modules//extra

但是可以用INSTALL_MOD_PATH指定安装目录-看另外一章



make-C$KDIRM=$PWDclean

删除所有构建模块生成的文件-没有更改内核源代码的目录.



make-C$KDIRM=`pwd`help

列出在构建外部模块可用的目标.



---2.3可用的选项:



$KDIR内核源代码路径



make-C$KDIR

用来指定内核源代码的路径.

''$KDIR''描述内核源代码的目录.Make会进入实际指定的目录执行,但是完成执行时会返回当前的目录.

make-C$KDORM=`pwd`

M=用来告诉kbuild正在构建一个外部模块.

M=是外部模块(kbuild文件)所在的目录.

make-C$KDIRSUBDIR=`pwd`

和M=选项一样,SUBDIRS=的语法是向后兼容的.



--2.4为构建模块准备内核树



为了确保构建外部模块所必需的内核信息,必须使用''modules_prepare''目标.

''modules_prepare''仅仅为构建外部模块简单地提供一个内核.

注意:modules_prepare没有构建模块,即使设置了CONFIG_MODULEVERSIONING.

因些,构建一个可工作版本的模块必须要一个完整的内核build.





===3.命令例子



这个例子显示了在为一个当前运行着内核构建一外部模块实际的命令.

在下面的例子是假设编译内核的输出文件和内核源代码的目录是不相同的,但是这个例子对于模块和内核树混合于不同的目录同样是适用的.



#内核源代码

/lib/modules//build->/usr/src/linux-



#来自内核编译的输出

/lib/modules//usr/src/linux--up



改变到kbuild文件的所在目录和执行以下的命令来构建模块:



cd/home/user/src/module

make-C/usr/src/`uname-r`/source\

-O=/lib/modules/`uname-r`/build\

M=`pwd`

之后执行以下的命令来安装模块:

make-C/usr/src/`uname-r`/source\

-O=/lib/modules/`uname-r`/build\

M=`pwd`\



如果你仔细看下你就会发现这个像之前的命令是一样的-只是目录转写出来而已.



上面的命令都很长,下面的章节将讲一些技巧来使它变得更简单.





===4.为外部模块创建一个kbuild文件.



kbuild是内核的编译系统,外部模块要构建系统中必须用kbuild来使改变保持兼容,和为gcc选择合适的标志(flags).



kbuild文件的用于输入的语法格式像/Documention/kbuild/makefiles.txt描述的那样.这个章节将会介绍更多的技巧用来处理外部的模块.



根据下面的文件来创建一个Makefile文件:

8123_if.c

8123_if.h

8123_pci.c

8123_bin.o_shipped<=Binaryblob



---4.1内核与模块之间共享Makefile



一个外部模块通常包括一个已经封闭好了的Makefile,编译这个模块只要''make''就可以而不必要另加参数.另外Makefile还提供了更多的功能,像测试目标等等这样的功能.如果这部份的名字冲突影响了kduild,必须把这部分过滤掉.



例1:

-->文件名:Makefile

ifneq($(KERNELRELEASE),)

#makefile中kbuild的部分

obj-m:=8123.o

8123-y:=8123_if.o8123_pci.o8123_bin.o

else

#通用的Makefile形式

KERNELDIR:=/lib/modules/`uname-r`/build

all:

$(MAKE)-C$(KERNELDIR)M=`pwd`$@

#Modulespecifictargets

genbin:

echo"X">8123_bini.o_shipped

endif



在例子1里面检查KERNELRELEASE是用来分离Makdefile的两部分的.kbuild只看到前面两个赋值语句,而make即除了这两个语句以外其它的都可以看到.



在近版本的内核,kbuild查找一命名为Kbuild的文件,而命名为Makefile为第二个参数.利用Kbuild

文件可以把例子1中的Makefile分裂成像例子2那样:



例子2:

-->filename:Kbuild

obj-m:=8123.o

8123-y:=8123_if.o8123_pci.o8123_bin.o



-->filename:Makefile

KERNELDIR:=/lib/modules/`uname-r`/build

all::

$(MAKE)-C$KERNELDIRM=`pwd`$@



#Modulespecifictargets

genbin:

echo"X">8123_bin_shipped



在例子2中我们相当简单地把文件分裂成两个简单的文件,那是值得怀疑的.但是一些外部模块用几百行的Makefile.在这里真正地从余下的份离出kbuild部分.

例子3表明了向后兼容的版本.



例子3:

-->文件名:Kbuild

obj-m:=8123.o

8123-y:=8123_if.o8123_pci.o8123_bin.o



-->文件名:Makefile

ifneq($(KERNELRELEASE),)

includeKbuild

else

#NormalMakefile



KERNELDIR:=/lib/modules/`uname-r`/build

all:

$(MAKE)-C$KERNELDIRM=`pwd`$@



#Modulespecifictargets

genbin:

echo"X">8123_bin_shipped



endif



这里用的技巧是:Makefile里包含了Kbuild文件,当是一个旧的版本kbuild的时候,Kbuild就会被包含进去.



---4.2模块中包含二进blob

一些外部模块需要包含一些以a.o为后缀的二进制blob.kbuild可以支持这种方法.但是必须要把文件命名成_shipped.在我们这个例子中,这个blob是8213_bin.o_shipped.当kbuild构建时只要把后缀去掉就可以.这样就允许了模块中分配了8123_bin.o中的内容.



例子4:

obj-m:=8123.o

8123-y:=8123_if.o8123_pci.o8123_bin.o

在例子4里的.c/.h源文件与二进制文件没有区别,但是kbuild可以选择不同的规则来创建.o文件.



===5.包含文件

当一个.c文件用到另一个.c文件的时候,就要用到包含文件(不是严格意义上的.c文件,但是良好的编程习惯是那样用).任何模块包含多个.c文件都会有一个多个.c文件的.h文件.

-如果.h文件只是描述一个模块的内部接口,那么.h文件必须和.c文件放在相同的目录下.

-如果.h文件描述的接口功能是内核的其它目录,而不是和当前模块在同一个目录时,这个.h文件即放在include/linux/或者其它适当的目录,一般根据其功能来划分.

另外,对于大的子系统即有一个规则,它们在include/下都有自己的包含目录.像include/scsi.另一个例外即是与特殊架构相关的头文件都在include/asm-$(ARCH)/.



对于外部模块即有一个倾向把包含文件放在一个独立的include/目录里,因些在他们的kbuild文件里要对这些作处理.



---5.1如何从内核包含目录中包含文件?

当一个模块要从目录include/linux/下包含一个文件,只要像下面这样:

#include



kbuild将确保新增的参数选项给gcc使它查找相关的目录.

同样,如果.h文件与.c文件放在相同的目录下,即像下面一样:

#include"8123_if.h"

---5.2外部模块包含目录include/dir

外部模块通常把它的.h文件放在单独的include/目录.虽然这通常不是内核的风格.当一个外部模块采用这样的包含目录,kbuild必须被告知.有个技巧就是用EXTRA_CFLAGS(对所有的.c文件都适用)或者CFLAGS_$F.o(对单个文件适用).



在我们的例子中,如果我们把8123_if.h文件到一个命名为include/的子目录.那么kbuild文件就像下面一样:



-->filename:Kbuild

obj-m:=8123.o



EXTRA_CFLAGS:=-Iinclude

8123-y:=8123_if.o8123_pci.o8123_bin.o



注意,在-I与目录间是没有空格的.这是kbuild里必须限制的且一定不出现空格.



===6.模块安装

内核模块安装在以下目录:



/lib/modules/$(KERNELRELEASE)kernel

外部模块安装在以下目录:

/lib/modules/$(KERNELRELEASE)extra



---6.1INSTALL_MOD_PATH

上面说的是默认的目录,但像以往一样,个性化地订制自己的目录也是允许的.我们可以使用安装前缀变量INSTALL_MOD_PATH:

$makeINSTALL_MOD_PATH=/frodomodules_install

=>Installdir:/frodo/lib/modules/$(KERNELRELEASE)/kernel



INSTALL_MOD_PATH像其它shell变量一样,如果在上述例子中指定了这个变量,调用make时,对内核模块和外部模块都是有效力的.



---6.2INSTALL_MOD_DIR

当安装外部模块时,它们会被默认安装到/lib/modules/$(KERNELRELEASE)/extra,但是如果你想把具体功能的模块放到单独的目录,基于这个目的,你可以用使用INSTALL_MOD_DIR参数来指定代替''extra''



$makeINSTALL_MOD_DIR=gandalf-CKERNELDIR\

M=`pwd`modules_install

=>Installdir:/lib/modules/$(KERNELRELEASE)/gandalf



====7.模块版本



CONFIG_MODVERSIONS标记启用模块版本.模块版本是用来作简单的ABI一致性检查的.模块版本为一个导出符号原型创建一个CRC值.当一个模块被加载时,内核中的CRC值与模块中同类值比较,如果不相等,内核即拒绝加载这个模块.



在构建内核的过程中会产生一个名为Module.symvers的文件.这个文件包含了内核中所有的符号版本.如果Module.symvers文件是最新编译内核时产生的,即不必再完整地编译内核来建立一个兼容的模块.



===8.提示和技巧



---8.1测试CONFIG_FOO_BAR

当kbuild是用来直接引用CONFIG_变量时,模块往往需要检查某些CONFIG_选项,以决定是否具体特性应包括在模块以内。



#fs/ext2/Makefile

obj-$(CONFIG_EXT2_FS)+=ext2.o



ext2-y:=balloc.obitmap.odir.o

ext2-$(CONFIG_EXT2_FS_XATTR)+=xattr.o



外部模块历来用传统的grep办法来直接检查在.config文件中的具体CONFIG_设置.这种方法已经被打破了.正如之前介绍的外部模块时,应使用kbuild建立.因此,可以使用相同的方法,在内核模块时测试CONFIG_的定义。

献花(0)
+1
(本文系望语气首藏)