本文主要介绍Linxu2.6的内核配置系统。
假如你浏览一下源代码目录,就可以发觉源码目录及其子目录中有好多的KConfig文件和Makefile文件。那些文件哪些作用呢?正是这种文件组成了Linux2.6的内核配置系统。
一、makemenuconfig的背后------KConfig文件的组织
有没有想过,我们makemenuconfig后,显示的那种菜单列表是如何来的?
带着这个疑惑,我们先来简单学一下Kconfig文件的“语法”。
source关键字:
用法:source
这个关键字相当于C语言里的“include”关键字,source旁边跟一个文件名,相当于把该文件的内容复制到当前位置。下边是源码目录的arch/arm目录下Kconfig文件的部份内容。
通过这些source引用,可以引入好多其他子目录中的Kconfig文件,并且引入的Kconfig文件中,还可以继续通过source来引入下一级的Kconfig文件。这样的结构就可以将所有的Kconfig文件包含进来。
一个菜单项(或叫配置项)的基本组成:config、bool(tristate)、default、prompt、help
一个简单的菜单项:
其中,config关键字表示新定义一个菜单项,前面跟的是这个菜单项的名子(ARCH_IXP23XX)。bool标示这个菜单项是bool类型,也就是这一项只能有两个值Y和N,再者还有一种最常用的类型,tristate三态型,这种类型的可以有三个值,Y/M/N,这三个值的意义在(上)篇中早已说过了。前面的“IXP23XX-based”是这个菜单项的描述,就是在makemenuconfig时我们能看见的,如右图:
在菜单列表里我们并看不到一个菜单项的名子,而只能看见它的描述,由于看它的描述更易于我们理解这个菜单项的意义,便捷我们配置。关于菜单项的描述,还有一个prompt关键字,举例说明其用法。例如下边两段是等效的
----------------------------------
CONFIGMY_MENU
bool
prompt"thisismymenu"
----------------------------------
CONFIGMY_MENU
bool"thisismymenu"
----------------------------------
就是说,一个菜单项的描述,可以直接跟在其类型(bool)的旁边来进行申明linux 内核编译文件说明,也可以由prompt关键字申明。
关于default关键字,截图中并未出现,但也是很常用的,它表明一个菜单项的默认值。如
defaulty
在步入菜单列表时,可以发觉好多菜单项都有默认值,这种默认值就是通过Kconfig文件里的default定义的。
还有一个help关键字,help关键字前面的内容是帮助信息,就是我们点击右下角的heip时显示的关于这个菜单项的帮助信息。下边是关于上图所示的菜单项的帮助信息:
菜单项间的依赖关系:select和dependson
还拿里面的反例来说明,第三行"dependsonMMU"。这一行是说,如今定义的"ARCH_IXP23XX"这个菜单项的值(Y/N)依赖于MMU这个菜单项的值。当MMU这个菜单项为N时,ARCH_IXP23XX只能为N。ARCH_IXP23XX的值必须“小于”MMU的值。(对于bool型,Y>N;对于tristate型,Y>M>N)。
select关键字的作用恰与dependson相反,它描述了一个反依赖的关系。以第五行"selectPCI"为例,PCI的值依赖于ARCH_IXP23XX。在定义PCI这个菜单项时,也要加上这样一句:"dependsonARCH_IXP23XX"。
按照各菜单项之间的依赖关系,在makemenuconfig时,系统会手动将这种相关联的菜单项整理成菜单项与子菜单项的方式,如右图
第二张图中的菜单项都依赖于"Enabletheblocklayer"对应的菜单项,所以系统将它们整理成子菜单项。只有"Enabletheblocklayer"对应的菜单项不为N时,这种子菜单项才可以配置。
menu与endmenu关键字
这个关键字主要是为了给菜单项分组,使菜单结构看上去更有条理。menu拿来定义一个子菜单,这个子菜单里包括一些相关的菜单项,在menu和endmenu关键字之间定义的菜单项都属于这个子菜单。还以那前面两张图为例,"Enabletheblocklayer----->"菜单项下边的"systemtype--->"就是一个子菜单的名称。将这个子菜单展开就可以看见这个子菜单包含的菜单项了。
menu"Systemtype"
config……
…………
config……
…………
config………
…………
…………
endmenu
这儿再额外解释一下,在里面的图中,"Enabletheblocklayer--->"和"systemtype-->",这两个其实看上去很像,都可以展开,但其性质是不同的。后者是按照各菜单项间的依赖关系构建上去的,"Enabletheblocklayer"本身就对应一个菜单项或则说配置项,它也有自己的值(Y/M/N),而"systemtype"则只是一个子菜单的名称linux系统下载官网,它下边包含了一些相关的配置项,但他本身不对应某个配置项,因此没有值(所以菜单列表中"systemtype--->"的后面没有*或M那些符号)。
choices与endchoice关键字
跟menu与endmenu用法基本一样,惟一的区别在于,choices定义的“子菜单”(应当叫选项表)中的多个菜单项只能有一个被选中,相当于menu定义一个可多选的子菜单,choices定义一个单选的子菜单。篇幅限制,不再截图阐述。
if与endif关键字
这两个真心不用解释,宽恕我直接略过。
comment关键字
拿来在菜单列表中插入一行文字,也是为了优化菜单结构。
如上图中的第四、五行,就是通过comment"ProcessorType"和comment"ProcessorFeatures"插入的。这两行既不能展开,也不能被配置,她们只是为菜单列表分段的一行文字。
总算把Kconfig中的关键字连图带字的解说完了,好冷啊。(好多教材和博客上介绍这种关键字的时侯都是只有文字描述,而不结合makemenuconfig后出现的菜单界面联系着说明,读上去不够直观,如今我就把这种整理下来,供菜鸟们快速把握和理解那些关键字的作用)。你们如今可以试着去阅读一个Kconfig文件了。
好了,对那些关键字有了认识以后,我们来说一下这个菜单列表的产生过程。运行makemenuconfig后,系统的配置工具先剖析与体系结构对应的/arch/ARCH/Kconfig
文件(这儿出现的ARCH参数在本文最后会谈到。它似乎指的就是所用的),/arch/ARCH/Kconfig文件中定义了一个主菜单mainmenu,它不仅包含一些配置项和配置菜单以外,还通过source句子引用了一系列其他子目录中的Kconfig文件,被引用进来的Kconfig文件内部可能再度通过source引入下一级目录中的Kconfig,系统就按照所有那些Kconfig文件中包含的菜单项(配置项)产生了菜单列表,之后按照用户对各个菜单项设置的值,最后生成.config文件。
二、另一个重要角色------kbuildMakefile的介绍
Kconfig文件帮助用户完成配置过程,而真正编译内核则是在各个子目录中的一系列Makefile共同完成的。Makefile中的重要句型就三个,比较好理解,这儿直接引用书中的内容。我把须要注意的地方用斜体标识。
引自华清远见嵌入式培训中心宋宝华编绘的《Linux设备驱动开发解读》(这本书真的挺好,须要电子版的同仁可以直接联系我):
(1)目标定义。
目标定义拿来定义什么内容要作为模块编译,什么要编译并联接进内核。
比如:
obj-y+=foo.o
表示要由foo.c或则foo.s文件编译得到foo.o并联接进内核,而obj-m则表示该
文件要作为模块编译。不仅y、m以外的obj-x方式的目标都不会被编译。
而更常见的做法是按照.config文件的CONFIG_变量来决定文件的编译形式,如
下所示:
obj-$(CONFIG_ISDN)+=isdn.o
obj-$(CONFIG_ISDN_PPP_BSDCOMP)+=isdn_bsdcomp.o
不仅obj-方式的目标以外,还有lib-ylibrary库、hostprogs-y主机程序等目标,但
是基本都应用在特定的目录和场合下。
(2)多文件模块的定义。
假如一个模块由多个文件组成,这时侯应采用模块名加-objs后缀或则-y后缀的形
式来定义模块的组成文件。如下边的事例所示:
obj-$(CONFIG_EXT2_FS)+=ext2.o
ext2-y:=balloc.obitmap.o
ext2-$(CONFIG_EXT2_FS_XATTR)+=xattr.o
模块的名子为ext2,由balloc.o和bitmap.o两个目标文件最终联接生成ext2.o直
至ext2.ko文件,是否包括xattr.o取决于内核配置文件的配置情况。假如
CONFIG_EXT2_FS的值是y也没有关系,在此过程中生成的ext2.o将被联接进
built-in.o最终联接进内核。这儿须要注意的一点是,该kbuildMakefile所在的目录中
不能再包含和模块名相同的源文件如ext2.c/ext2.s。
或则写成如-objs的方式:
obj-$(CONFIG_ISDN)+=isdn.o
isdn-objs:=isdn_net_lib.oisdn_v110.oisdn_common.o
(3)目录层次的迭代。
示例:
obj-$(CONFIG_EXT2_FS)+=ext2/
当CONFIG_EXT2_FS的值为y或m时,kbuild将会把ext2目录纳入向上迭代的
目标中,具体ext2目录下的文件是要作为模块编译还是链入内核由ext2目录下的
Makefile文件的内容决定。
引用结束。
前面所述的(3)非常关键,目录层次的迭代致使整个Makefile系统呈现一个树形结构linux 内核编译文件说明,条理清晰,加载新的编译目录也很便捷。
三、牛刀初试
如果我们自己开发了一个新的模块,要怎么能够把我们自己的模块加到配置系统中?里面早已介绍了Kconfig和Makefile文件的基本句型,为了确保我们把握了这两种文件的配置方式,我们最好做一下练习,。这儿我要再度偷懒,直接COPY书中内容了。
引用开始:
下边讲解一个综合实例,假定我们要在内核源代码drivers目录下为ARM体系结
构新增如下用于testdriver的树型目录:
|--test
|--cpu
|--cpu.c
|--test.c
|--test_client.c
|--test_ioctl.c
|--test_proc.c
|--test_queue.c
在内核中降低目录和子目录,我们需为相应的新增目录创建Kconfig和Makefile
文件,而新增目录的父目录中的Kconfig和Makefile文件也须要更改,便于新增的
Kconfig和Makefile文件能被引用。
在新增的test目录下,应当包含如下Kconfig文件:
#
#TESTdriverconfiguration
#
menu"TESTDriver"
comment"TESTDriver"
configCONFIG_TEST
bool"TESTsupport"
configCONFIG_TEST_USER
tristate"TESTuser-spaceinterface"
dependsonCONFIG_TEST
endmenu
因为TESTdriver对于内核来说是新的功能,所以首先须要创建一个菜单TEST
Driver;之后显示“TESTsupport”,等待用户选择;接出来判定用户是否选择了TEST
Driver,倘若是(CONFIG_TEST=y),则进一步显示子功能:用户插口与CPU功能支
持;因为用户插口功能可以被编译成内核模块,所以这儿的寻问句子使用了tristate。
为了使这个Kconfig文件能起作用,须要更改arch/arm/Kconfig文件,降低以下内
容:
source"drivers/test/Kconfig"
脚本中的source意味着引用新的Kconfig文件。
在新增的test目录下,应当包含如下Makefile文件:
#drivers/test/Makefile
#
#MakefilefortheTEST.
#
obj-$(CONFIG_TEST)+=test.otest_queue.otest_client.o
obj-$(CONFIG_TEST_USER)+=test_ioctl.o
obj-$(CONFIG_PROC_FS)+=test_proc.o
obj-$(CONFIG_TEST_CPU)+=cpu/
该脚本按照配置变量的取值建立obj-*列表。因为test目录中包含一个子目录cpu,
当CONFIG_TEST_CPU=y时,须要将cpu目录加入列表。
test目录中的cpu子目录也需包含如下的Makefile文件:
#drivers/test/test/Makefile
#
#MakefilefortheTESTCPU
#
obj-$(CONFIG_TEST_CPU)+=cpu.o
为了促使整个test目录就能被编译命令作用到,test目录父目录中的Makefile文
件也需新增如下脚本:
obj-$(CONFIG_TEST)+=test/
在drivers/Makefile中加入obj-$(CONFIG_TEST)+=test/,致使用户在进行内核编
译时才能步入test目录。
降低了Kconfig和Makefile文件以后的新的test树型目录如下所示:
|--test
|--cpu
|--cpu.c
|--Makefile
|--test.c
|--test_client.c
|--test_ioctl.c
|--test_proc.c
|--test_queue.c
|--Makefile
|--Kconfig
附:(顶楼Makefile中的ARCH参数、编译ARM平台Linux内核的方式)
源代码目录顶楼目录中的Makefile文件被叫做顶楼Makefile,它上面涉及到一个ARCH参数,还有一个CROSS_COMPILE参数,分别对应处理器内核构架和交叉编译器。通常情况下,ARCH默认为x86,CROSS_COMPILE默认也是x86平台上的交叉编译器。在执行makemenuconfig,makebzImage,makemodules等命令时,系统就会首先剖析ARCH的值,依据选择的平台来执行相应操作。为此,假如想编译ARM平台的Linux内核,在输入相应命令时要加上构架和交叉编译器选项,如
makeARCH=armCROSS_COMPILE=arm-linux-menuconfig
makeARCH=armCROSS_COMPILE=arm-linux-bzImage
makeARCH=armCROSS_COMPILE=arm-linux-modules
倘若直接将
ARCH=arm
CROSS_COMPILE=arm-linux-
这两行添加到顶楼Makefile的开头,就可以将ARCH和CROSS_COMPILE的默认值改成"arm"和"arm-linux-"了。之后再编译ARM平台的Linux内核时就可以直接使用makemenuconfig/bzImage/modules等命令,而不用再加"ARCH=armCROSS_COMPILE=arm-linux-"。