分类： LINUX
2012-01-07 10:39:24
Linux 2.6 内核的配置系统由以下 3 个部分组成：
> Makefile：分布在 Linux 内核源代码中的 Makefile，定义 Linux 内核的编译规则
> 配置文件 Kconfig：给用户提供配置选择的功能
> 配置工具：包括配置命令解释器（对配置脚本中使用的配置命令进行解释）和配置用户界面（提供字符界面和图形界面）。这些配置工具都是使用脚本语言编写的，如 Tcl/TK、perl 等。
在Linux 内核中增加程序需要完成以下 3 项工作：
> 1. 将编写的源代码复制到 Linux 内核源代码的相应目录
> 2. 在目录的Kconfig 文件中增加新源代码对应项目的编译配置选项
> 3. 在目录的 Makefile 文件中增加对新源代码的编译条目
1. 实例引导：S3C2440 处理器的RTC 与 LED 驱动配置。
首先，在Linux/drivers/char 目录中包含了 S3C2410 处理器的 RTC 设备驱动源代码 s3c2410-rtc.c。
而在该目录的 Kconfig 文件中包含 S3C2410_RTC 的配置项目：
config S3C2410_RTC
bool "S3C2410 RTC Driver"
depends on ARCH_S3C2410
help
RTC （Realtime Clock）driver for the clock inbuilt into the Samsung S3C2410. This can provide periodic interrupt rates from 1Hz to
64Hz for user programs, and wakeup from Alarm.
上述 Kconfig 文件的这段脚本意味着只有在 ARCH_S3C2410 项目被配置的情况下，才会出现 S3C2410_RTC 配置项目，这个配置项目为布尔型（要么编译入内核，要么不编译，选择 "Y" 或 "N" ），菜单撒很难过显示的字符串为 "S3C2410 RTC Driver"，"help" 后面的内容为帮助信息。
除了布尔型的配置项目外，还存在一种三态型（tristate）配置选项，它意味着要么编译入内核，要么编译为内核模块，选项为"Y"、"M” 或"N"。
在目录的Makefile 中关于 S3C2410_RTC 的编译脚本为：
obj-$(CONFIG_S3C2410_RTC) += s3c2410-rtc.o
上述脚本意味着如果 S3C2410——RTC 配置选项背选择为 "Y" 或 "M"，即 obj-$(CONFIG_S3C2410_RTC) 等同于 obj-y 或 obj-m 时，则编译 s3c2410-rtc.c，选择 "Y" 的情况直接会将生成的目标代码直接连接到内核，为"M" 的情况则生成模块 s3c2410-rtc.ko（由于 S3C2410_RTC 为布尔型，实际不会为"M"）；如果 S3C2410_RTC 配置选项将选择为 "N"，即 obj-$(CONFIG_S3C2410_RTC) 等同于 obj-n 时，则不编译 s3c2410-rtc.c。
一般而言，驱动工程师在内核源代码的 drviers 目录的相应子目录中增加新设备驱动的源代码，并增加或修改 Kconfig 配置脚本和Makefile 脚本，完全仿照上述过程执行即可。
再如，为S3C2410 的LED 编写了驱动，源代码为 s3c2410-led.c，为使内核能支持对该模块的编译配置，应进行如下 3 项处理。
> 将编写的 s3c2410-led.c 源代码复制到 linux/drivers/char 目录
> 在目录的 Kconfig 文件中增加 LED 的编译配置选项，如下所示：
config S3C2410_LED
bool "S3C2410 LED Driver"
depends on ARCH_S3C2410
help
LED driver for the Samsung S3C2410.
> 在目录的 Makefile 文件中增加对 s3c2410-led.c 源代码的编译，如下所示：
obj-$(CONFIG_S3C2410_LED) += s3c2410-led.o
2. Makefile
下面对内核源代码各级子目录中的 kbuild Makefile 进行介绍，这部分是内核模块或设备驱动的开发者最常接触到的。
kbuild Makefile 的语法包括如下几个方面。
（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-y library库、hostprogs-y 主机程序等目标，但是基本都应用在特定的目录和场合下。
（2）多文件模块的定义
如果一个模块由多个文件组成，这时候应采用模块名加 -objs 后缀或者 -y 后缀的形式来定义模块的组成文件。如下面的例子所示：
obj-$(CONFIG_EXT2_FS) += ext2.o
ext2-y := balloc.o bitmap.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 最终连接进内核。这里需要注意的一点是，该 kbuild Makefile 所在的目录中不能再包含和模块名相同的源文件和 ext2.c/ext2.s。
或者写如 -objs 的形式：
obj-$(CONFIG_ISDN) +=isdn.o
isdn-objs := isdn_net_lib.o isdn_v110.o isdn_common.o
（3）目录层次的迭代
示例：obj-$(CONFIG_EXT2_FS) += ext2/
当 CONFIG_EXT2_FS 的值为 y 或 m时，kbuild 将会把 ext2 目录列入向下迭代的目标中，具体 ext2 目录下的文件是要作为模块编译还是链入内核由 ext2 目录下的 Makefile 文件的内容决定。
3. Kconfig
（1）菜单入口
大多数的内核配置选项都对应 Kconfig 中的一个菜单入口，如下所示：
config MODVERSIONS
bool "Set version information on all module symbols"
depends on MODULES
help
Usually, modules have to be recompiled whenever you switch to a new kernel.....
"config" 关键字定义新的配置选项，之后的几行定义了该配置选项的属性。配置选项的属性包括类型、数据范围、输入提示、依赖关系（及反向依赖关系）、帮助信息和默认值等。
每个配置选项都必须制定类型，类型包括bool、tristate、string、hex 和 int，其中 tristate 和string 是两种基本的类型，其他类型都基于这两种基本类型。类型定义后可以紧跟输入提示，下面的两段脚本是等价的。
脚本1： bool "Networking support"
脚本2: bool
prompt "Networking support"
输入提示的一般格式的如下所示：
prompt
其中可选的 if 用来表示该提示的依赖关系。
默认值的格式如下所示： default
一般配置选项可以存在任意多个默认值，这种情况下，只有第一个被定义的值是可用的。如果用户不设置对应的选项，配置选项的值就是默认值。
依赖关系的格式如下所示：depends on (或者 requires)
如果定义了多个依赖关系，他们之间用 “&&”间隔。依赖关系也可以应用到该菜单中所有的其他选项中（这些选项同样可接受 if 表达式），下面的两端段脚本是等价的。
脚本1： bool "foo" if BAR
default y if BAR
脚本2: depends on BAR
bool "foo"
default y
反向依赖关系的格式如下所示：select
depends能限定一个 symbol 的上限，即如果 A 依赖于 B，则在 B 被配置为 "Y" 的情况下，A 可以为“Y"、"M" 和"N"；在 B 被配置为 “M" 情况下，A 可以被配置为"M" 或 "N"；B 在被配置为 "N" 的情况下，A 只能为 “N"。
select 能限定一个 symbol 的下限，若 A 反向依赖于 B，则 A 的配置值会高于或等于 B（正好与 depends)。如果 symbol 反向依赖于多个对象，则它的下陷是这些对象的最大值。
kbuild Makefile 中的 expr (表达式） 定义如下所示：
' ( '
' ! '
也就是说 expr 是由 symbol 、两个 symbol 相等、两个symbol 不等以及 expr 的赋值、非、与、或运算构成。而 symbol 分为两类，一类是由菜单入口定义配置选项定义的非常数 symbol，另一类是作为 expr 组成部分的常数 symbol。
数据范围的格式如下：
rang
为 int 和 hex 类型的选项设置可以接受的输入值范围，用户只能输入大于等于第一个 symbol，小于等于第二个 symbol 的值。
帮助信息的格式如下： help(或 --help--)
开始
.....
结束
帮助信息完全靠文本缩进识别结束。"--help--" 和 "help" 在作用上没有区别，设计"--help--" 的初衷在于将文件中的配置逻辑与给开发人员的提示分开。
menuconfig 关键字的作用与 config 类似，但它在 config 的基础上要求所有的子选项作为独立的行显示。
（2）菜单结构
菜单入口在菜单树结构中的位置可由两种方法决定。第一种方式如下所示：
menu "Networking device support"
depends on NET
config NETDEVICES
....
endmenu
所有处于"menu" 和 "endmenu" 之间的菜单入口都会成为 "Network device support" 的子菜单。而且，所有子菜单选项都会继承父菜单的依赖关系，比如，" Network device support" 对 "Net" 的依赖被加到了配置选项 NETDEVICES 的依赖列表中。
另一种方式是通过分析依赖关系生成菜单结构。如果菜单选项在一定程度上依赖于前面的选项，它就恩能能成为该选项的子菜单。如果父选项为 "N"，则子选项不可见；如果父选项为 "Y" 或 "M" ，则子选项可见，例如：
config MODULES
bool "Enable loadable module support"
config MODVERSIONS
bool "Set version information on all module symbols"
depends on MODULES
comment "module support disabled"
depends on !MODULES
MODVERSIONS 直接依赖 MODULES，如果 MODULES 不为 “N"，该选项才可见。
除此之外，Kconfig 中还可能使用 “choices.....endchoice"、"comment"、"if ... endif" 这样的语法结构。其中 "choices .. endchoice” 的结构如下所示：
choice
endchoice
它定义一个选择群，其接受的选项（chioce options）可以是前面描述的任何属性。在一个硬件有多个驱动的情况下使用，使用选择可以实现最终只有一个驱动被编译进内核或模块。选择群还可以接受的另一个选项是“optional”，这样菜单入口就被设置为 "N"，没有被选中。
4. 应用实例：在内核中新增加驱动代码目录和子目录
假设要在内核源代码 drivers 目录下为 ARM 体系结构新增如下用于 test driver 的树型目录：
|--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 文件：
#
#Test driver configuration
#
menu "TEST Driver"
comment " TEST Driver"
config CONFIG_TEST
bool "TEST support"
config CONFIG_TEST_USER
tristate "TEST user-space interface"
depends on CONFIG_TEST
endmenu
由于 TEST_driver 对于内核来说是新的功能，所以首先需要创建一个菜单 TEST Driver；然后显示" TEST support"，等待用户选择；接下来判断用户是否选择了 TEST Driver，如果是（CONFIG_TEST=y），则进一步显示子功能：用户接口与CPU 功能：用户接口与CPU 功能支持；由于用户接口功能可以被编译成内核模块，所以这里的询问语句使用了 tristate。
为了使这个 Kconfig 文件能起作用，需要修改 arch/arm/Kconfig 文件，增加以下内容：
source "driver/test/Kconfig"
脚本中的 source 意味着引用新的 Kconfig 文件。
在新增的 test 目录下，应该包含如下 Makefile 文件：
#drivers/test/Makefile
# Makefile for the TEST
#
obj-$(CONFIG_TEST) +=test.o test_queue.o test_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
#Makefile for the TEST CPU
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
|--test.c
|--test_client.c
|--test_ioctl.c
|--test_proc.c
|--test_queue.c
|--Makefile
|--Kconfig
文章转自：
http://vicyliu1984.blog.163.com/blog/static/315412322010107112226488/
