ARM内核和驱动（15）
本文主要介绍Linxu2.6的内核配置系统。
如果你浏览一下源代码目录，就可以发现源码目录及其子目录中有很多的KConfig文件和Makefile文件。这些文件什么作用呢？正是这些文件组成了Linux2.6的内核配置系统。
一、make menuconfig的背后------KConfig文件的组织
有没有想过，我们make menuconfig后，显示的那个菜单列表是怎么来的？
带着这个疑问，我们先来简单学一下Kconfig文件的“语法”。
source 关键字：
用法：source &filename&
这个关键字相当于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”是这个菜单项的描述，就是在make menuconfig时我们能看到的，如下图：
在菜单列表里我们并看不到一个菜单项的名字，而只能看到它的描述，因为看它的描述更便于我们理解这个菜单项的意义，方便我们配置。关于菜单项的描述，还有一个prompt关键字，举例说明其用法。比如下面两段是等效的
----------------------------------
CONFIG MY_MENU
prompt &this is my menu&
----------------------------------
CONFIG MY_MENU
bool &this is my menu&
----------------------------------
就是说，一个菜单项的描述，可以直接跟在其类型(bool)的后面来进行声明，也可以由prompt关键字声明。
关于default关键字，截图中并未出现，但也是很常用的，它表明一个菜单项的默认值。如
在进入菜单列表时，可以发现很多菜单项都有默认值，这些默认值就是通过Kconfig文件里的default定义的。
还有一个help关键字，help关键字后面的内容是帮助信息，就是我们点击右下角的heip时显示的关于这个菜单项的帮助信息。下面是关于上图所示的菜单项的帮助信息：
菜单项间的依赖关系：select和depends on
还拿上面的例子来说明，第三行&depends on MMU&。这一行是说，现在定义的&ARCH_IXP23XX&这个菜单项的值(Y/N)依赖于MMU这个菜单项的值。当MMU这个菜单项为N时，ARCH_IXP23XX只能为N。ARCH_IXP23XX的值必须“小于”MMU的值。（对于bool型，Y&N；对于tristate型，Y&M&N）。
select关键字的作用恰与depends on相反，它描述了一个反依赖的关系。以第五行&select PCI&为例，PCI的值依赖于ARCH_IXP23XX。在定义PCI这个菜单项时，也要加上这样一句：&depends on ARCH_IXP23XX&。
根据各菜单项之间的依赖关系，在make menuconfig时，系统会自动将这些相关联的菜单项整理成菜单项与子菜单项的形式，如下图
第二张图中的菜单项都依赖于&Enable the block layer&对应的菜单项，所以系统将它们整理成子菜单项。只有&Enable the block layer&对应的菜单项不为N时，这些子菜单项才可以配置。
menu与endmenu关键字
这个关键字主要是为了给菜单项分组，使菜单结构看起来更有条理。menu用来定义一个子菜单，这个子菜单里包括一些相关的菜单项，在menu和endmenu关键字之间定义的菜单项都属于这个子菜单。还以那上面两张图为例，&Enable the block layer-----&&菜单项下面的&system type---&&就是一个子菜单的名称。将这个子菜单展开就可以看到这个子菜单包含的菜单项了。
menu &System type&
config ……
config……
config………
这里再额外解释一下，在上面的图中，&Enable the block layer---&&和&system type--&&，这两个虽然看起来很像，都可以展开，但其性质是不同的。前者是根据各菜单项间的依赖关系建立起来的，&Enable the block layer&本身就对应一个菜单项或者说配置项，它也有自己的值(Y/M/N)，而&system type&则只是一个子菜单的名称，它下面包含了一些相关的配置项，但他本身不对应某个配置项，因而没有值（所以菜单列表中&system
type---&&的前面没有*或M这些符号）。
choices与endchoice关键字
跟menu与endmenu用法基本一样，唯一的区别在于，choices定义的“子菜单”（应该叫选项表）中的多个菜单项只能有一个被选中，相当于menu定义一个可多选的子菜单，choices定义一个单选的子菜单。篇幅限制，不再截图详述。
if与endif关键字
这两个真心不用解释，原谅我直接略过。&
comment关键字
用来在菜单列表中插入一行文字，也是为了优化菜单结构。
如上图中的第四、五行，就是通过& comment &Processor Type&& 和 comment &Processor Features&插入的。这两行既不能展开，也不能被配置，他们只是为菜单列表分段的一行文字。
终于把Kconfig中的关键字连图带字的解说完了，好累啊。（很多教材和博客上介绍这些关键字的时候都是只有文字描述，而不结合make menuconfig后出现的菜单界面联系着说明，读起来不够直观，现在我就把这些整理出来，供新手们快速掌握和理解这些关键字的作用）。大家现在可以试着去阅读一个Kconfig文件了。
好了，对这些关键字有了认识之后，我们来说一下这个菜单列表的形成过程。运行make menuconfig后，系统的配置工具先分析与体系结构对应的/arch/ARCH/Kconfig
文件（这里出现的ARCH参数在本文最后会讲到。它其实指的就是所用的&cpu&），/arch/ARCH/Kconfig文件中定义了一个主菜单mainmenu，它除了包含一些配置项和配置菜单以外，还通过source语句引用了一系列其他子目录中的Kconfig文件，被引用进来的Kconfig 文件内部可能再次通过source 引入下一级目录中的Kconfig，系统就根据所有这些Kconfig文件中包含的菜单项（配置项）形成了菜单列表，然后根据用户对各个菜单项设置的值，最后生成.config文件。
二、另一个重要角色------kbuild Makefile的介绍
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-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）特别关键，目录层次的迭代使得整个Makefile系统呈现一个树状结构，条理清晰，加载新的编译目录也很方便。
三、牛刀初试
假如我们自己开发了一个新的模块，要如何才能把我们自己的模块加到配置系统中？上面已经介绍了Kconfig和Makefile文件的基本语法，为了确保我们掌握了这两种文件的配置方法，我们最好做一下练习，。这里我要再次偷懒，直接COPY书中内容了。
引用开始：
下面讲解一个综合实例，假设我们要在内核源代码drivers目录下为ARM体系结
构新增如下用于test driver 的树型目录：
| -- 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
由于TEST driver 对于内核来说是新的功能，所以首先需要创建一个菜单TEST
Driver；然后显示“TEST support”，等待用户选择；接下来判断用户是否选择了TEST
Driver，如果是（CONFIG_TEST=y），则进一步显示子功能：用户接口与CPU功能支
持；由于用户接口功能可以被编译成内核模块，所以这里的询问语句使用了tristate。
为了使这个Kconfig文件能起作用，需要修改arch/arm/Kconfig文件，增加以下内
source &drivers/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树型目录如下所示：
| -- 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平台上的交叉编译器。在执行make menuconfig,make bzImage,make modules等命令时，系统都会首先分析ARCH的值，根据选择的平台来执行相应操作。因此，如果想编译ARM平台的Linux内核，在输入相应命令时要加上架构和交叉编译器选项，如
make ARCH=arm CROSS_COMPILE=arm-linux- menuconfig
make ARCH=arm CROSS_COMPILE=arm-linux- bzImage
make ARCH=arm CROSS_COMPILE=arm-linux- modules
如果直接将
CROSS_COMPILE=arm-linux-
这两行添加到顶层Makefile的开头，就可以将ARCH和CROSS_COMPILE的默认值改成&arm&和&arm-linux-&了。以后再编译ARM平台的Linux内核时就可以直接使用make menuconfig/bzImage/modules等命令，而不用再加&ARCH=arm CROSS_COMPILE=arm-linux-&。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：22890次
排名：千里之外
原创：31篇
(1)(1)(3)(1)(3)(10)(1)(4)(4)(4)(2)1145人阅读
内核（20）
编译环境（3）
linux内核中Kconfig文档的作用以及Kconfig的语法【转】
linux内核中Kconfig文档的作用以及Kconfig的语法
2.6内核的源码树目录下一般都会有两个文文：Kconfig和Makefile。分布在各目录下的Kconfig构成了一个分布式的内核配置数据库，每个Kconfig分别描述了所属目录源文件相关的内核配置菜单。在内核配置make menuconfig(或xconfig等)时，从Kconfig中读出配置菜单，用户配置完后保存到.config(在顶层目录下生成)中。在内核编译时，主Makefile调用这个.config，就知道了用户对内核的配置情况。
上面的内容说明：Kconfig就是对应着内核的配置菜单。假如要想添加新的驱动到内核的源码中，可以通过修改Kconfig来增加对我们驱动的配置菜单，这样就有途径选择我们的驱动，假如想使这个驱动被编译，还要修改该驱动所在目录下的Makefile。
因此，一般添加新的驱动时需要修改的文件有两种（注意不只是两个）
要想知道怎么修改这两种文件，就要知道两种文档的语法结构。
First:&& Kconfig
每个菜单项都有一个关键字标识，最常见的就是config。
config symbol
&!--[if !supportLineBreakNewLine]--&
&!--[endif]--&
symbol就是新的菜单项，options是在这个新的菜单项下的属性和选项
options部分有：
1、类型定义：
每个config菜单项都要有类型定义，bool：布尔类型， tristate三态：内建、模块、移除， string：字符串， hex：十六进制， integer：整型
例如config HELLO_MODULE
bool &hello test module&
bool类型的只能选中或不选中，tristate类型的菜单项多了编译成内核模块的选项，假如选择编译成内核模块，则会在.config中生成一个 CONFIG_HELLO_MODULE=m的配置，假如选择内建，就是直接编译成内核影响，就会在.config中生成一个 CONFIG_HELLO_MODULE=y的配置.
&！！！ Kconfig 中变量取值类型总共有5种。其中做常见的是tristate 和 bool ，分别对应于make meuconfig 配置界面中& & 和 [ ]选项。
（1）tristate ：可取y& 、n 、m。
（2）bool (其为tristate的变体) ：可取 y 、n
（3）string ：取值为字符串，如：CONFIG_CMDLINE = &root =/dev/hdal&&&ro& init = /bin/bash& console =ttySAC0 &&
（4）hex （其为string的变体）：取值为十六进制数据，如：CONFIG_VECTORS_BASE =0xffff0000.
（5）int （其为string的变体）：取值为十进制数据，如：CONFIG_SPLIT_PTLOCK_CPUS=4096
2、依赖型定义depends on或requires&&指此菜单的出现是否依赖于另一个定义
config HELLO_MODULE
bool &hello test module&
depends on ARCH_PXA
&&& 这个例子表明HELLO_MODULE这个菜单项只对XScale处理器有效，即只有在选择了ARCH_PXA，该菜单才可见(可配置)。
3、帮助性定义 & &&只是增加帮助用关键字help或---help---
&!--[if !supportLineBreakNewLine]--&
&!--[endif]--&
更多详细的Kconfigconfig语法可参考：下文Linux2.6.X配置文件Kconfig的语法
Second: 内核的Makefile
内核的Makefile分为5个组成部分：
Makefile&&&& 最顶层的Makefile
.config&&&&&&& 内核的当前配置文档，编译时成为顶层Makefile的一部分
arch/$(ARCH)/Makefile 和体系结构相关的Makefile
s/ Makefile.*&&& 一些Makefile的通用规则
kbuild Makefile&&&&& 各级目录下的大概约500个文档，编译时根据上层Makefile传下来的宏定义和其他编译规则，将源代码编译成模块或编入内核。
顶层的Makefile文档读取 .config文档的内容，并总体上负责build内核和模块。Arch Makefile则提供补充体系结构相关的信息。 s目录下的Makefile文档包含了任何用来根据kbuild Makefile 构建内核所需的定义和规则。
（其中.config的内容是在make menuconfig的时候，通过Kconfig文档配置的结果）
在linux2.6.x/Documentation/kbuild目录下有详细的介绍有关kernel makefile的知识。
最后举个例子：
假设想把自己写的一个flash的驱动程式加载到工程中，而且能够通过menuconfig配置内核时选择该驱动该怎么办呢？能够分三步：
第一：将您写的flashtest.c 文档添加到/driver/mtd/maps/ 目录下。
第二：修改/driver/mtd/maps目录下的kconfig文档：
config MTD_flashtest
tristate “ap71 flash&
这样当make menuconfig时 ，将会出现 ap71 flash选项。
第三：修改该目录下makefile文档。
添加如下内容：obj-$(CONFIG_MTD_flashtest)&&& += flashtest.o
这样，当您运行make menucofnig时，您将发现ap71 flash选项，假如您选择了此项。该选择就会保存在.config文档中。当您编译内核时，将会读取.config文档，当发现ap71 flash 选项为yes 时，系统在调用/driver/mtd/maps/下的makefile 时，将会把 flashtest.o 加入到内核中。即可达到您的目的。
--------------------------------------------------------------------------------------------------------------------
Linux2.6.X配置文件Kconfig的语法
linux在2.6版本以后将配置文件由原来的config.in改为kconfig，对于kconfig的语法在/Documentation /kbuild/kconfig-language.txt中做了详细的说明，在这里给出kconfig-language.txt的中文版。
在配置数据库的配置选项是以树的形式组织的：
&& +- Code maturity level options
&& | +- Prompt for development and/or incomplete code/drivers
&& +- General setup
&& | +- Networking support
&& | +- System V IPC
&& | +- BSD Process Accounting
&& | +- Sysctl support
&& +- Loadable module support
&& | +- Enable loadable module support
&& |&&&& +- Set version information on all module symbols
&& |&&&& +- Kernel module loader
&& +- ...
每个选项都有其自己的依赖关系。这些依赖关系决定了选项是否是可见的。父选项可见，子选项才能可见。
大多数的选项都定义了一个配置选项，其它选项则有助于对它们进行组织。(原文：Most entries define
a config option, all other entries help to organize them.)一个配置选项定义可以是下面的形式：
config MODVERSIONS
&& bool &Set version information on all module symbols&
&& depends MODULES
&&&&& Usually, modules have to be recompiled whenever you switch to a new
&&&&& kernel. ...
每行都是以关键字开始，并可以接多个参数。&config& 为定义了一新的配置选项。下面的几行定义了该配置
选项的属性。属性可以是该配置选项的类型，输入提示(input prompt)，依赖关系，帮助信息和默认值。一
配置选项可以用相同的名字定义多次，但每个定义只能有一个输入提示并且类型还不能冲突。
一菜单选项可以有多个属性。并不要求这些属性可以用在任何地方(见语法)。
- 类型定义：&bool&/&tristate&/&string&/&hex&/&int&
每个配置选项都必须指定类型。有两个基本类型：tristate 和 string，其他类型都是基于这两个基本
类型。类型定义可以用输入提示，所以下面的两个例子是等价的：
&& bool &Networking support&
&& prompt &Networking support&
- 输入提示： &prompt& &prompt& [&if& &expr&]
每个菜单选项最多只能有一个显示给用户的输入提示。可以用 &if& 来表示该提示的依赖关系，当然这是
- 默认值：&default& &expr& [&if& &expr&]
一个配置选项可以有任意多个默认值。如果有多个默认值，那么只有第一个被定义的值是可用的。默认值并
不是只限于应用在定义他们的菜单选项。这就意味着默认值可以定义在任何地方或被更早的定义覆盖。
如果用户没有设置(通过上面的输入提示)，配置选项的值就是默认值。如果可以显示输入提示的话，就会把
默认值显示给用户，并可以让用户进行修改。
默认值的依赖关系可以用 &if& 添加。(可选项)
- 依赖关系：&depends on&/&requires& &expr&
为一菜单选项定义依赖关系。如果定义了多个依赖关系，它们之间用 '&&' 间隔。依赖关系也可以应用到
该菜单中所有的其它选项(同样接受一if表达式)，所以下面的两个例子是等价的：
&& bool &foo& if BAR
&& default y if BAR
&& depends on BAR
&& bool &foo&
&& default y
- 反向依赖关系：&select& &symbol& [&if& &expr&]
尽管普通的依赖关系可以降低一选项的上限，反向依赖能将这一限制降的更低。当前菜单选项的值是symbol
的最小值。如果symbol被选择了多次，上限就是其中的最大值。
反向依赖只能用在 boolean 或 tristate 选项上。
=======select与depends on是相反的逻辑关系。
& & & & & & & & & & & & & & & & & A depends on B &那么只有在B选中才能选A
& & & & & & & & & & & & & & & & & A select B & & & & & &那么只要选中A就会选中B
- 数据范围：&range& &symbol& &symbol& [&if& &expr&]
为int和hex类型的选项设置可以接受输入值范围。用户只能输入大于等于第一个symbol，小于等于第二个
symbol的值。
- 帮助信息： &help& or &---help---&
定义一帮助信息。帮助信息的结束就由缩进的水平决定的，这也就意味着信息是在第一个比帮助信息开始行
的缩进小的行结束。
&---help---& 和 &help& 在实现的作用上没有区别，&---help---& 有助于将文件中的配置逻辑与
给开发人员的提示分开。
菜单依赖关系
------------
依赖关系决定了菜单选项是否可见，也可以减少tristate的输入范围。tristate逻辑比boolean逻辑在表
达式中用更多的状态(state)来表示模块的状态。依赖关系表达式的语法如下：
&expr& ::= &symbol&&&&&&&&&&&&&&&&&&&&&&&&&&&&& (1)
&&&&&&&&&& &symbol& '=' &symbol&&&&&&&&&&&&&&&& (2)
&&&&&&&&&& &symbol& '!=' &symbol&&&&&&&&&&&&&&& (3)
&&&&&&&&&& '(' &expr& ')'&&&&&&&&&&&&&&&&&&&&&& (4)
&&&&&&&&&& '!' &expr&&&&&&&&&&&&&&&&&&&&&&&&&&& (5)
&&&&&&&&&& &expr& '&&' &expr&&&&&&&&&&&&&&&&&&& (6)
&&&&&&&&&& &expr& '||' &expr&&&&&&&&&&&&&&&&&&& (7)
表达式是以优先级的降序列出的。
(1) 将symbol赋给表达式。boolean和tristate类型的symbol直接赋给表达式。所有其它类型的symbol
&&& 都赋 'n'。
(2) 如果两个symbol相等，返回'y'，否则为'n'。
(3) 如果两个symbol相等，返回'n'，否则为'y'。
(4) 返回表达式的值。用于改变优先级。
(5) 返回 (2-/expr/) 的结果。
(6) 返回 min(/expr/,/expr/) 的结果。
(7) 返回 max(/expr/,/expr/) 的结果。
一个表达式的值可以是'n'，'m'或'y'(或者是计算的结果 0,1,2）。当表达式的值为'm'或'y'的时候，菜
单项才是可见的。
symbol有两种类型：不可变的和可变的。不可变的symbol是最普通的，由'config'语句定义，完全由数字
、字母和下划线组成(alphanumeric characters or underscores)。
不可变的symbol只是表达式的一部分。经常用单引号或双引号括起来。在引号中，可以使用任何字符，使用引
号要用转义字符'\'。
菜单在树中的位置可由两种方法决定。第一种可以是这样：
menu &Network device support&
&& depends NET
config NETDEVICES
所有的在&menu& ... &endmenu& 之间都是&Network device support&的子菜单。所有的子菜单选项
都继承了父菜单的依赖关系，比如，&NET&的依赖关系就被加到了配置选项NETDEVICES的依赖列表中。
还有就是通过分析依赖关系生成菜单的结构。如果菜单选项在一定程度上依赖于前面的选项，它就能成为该选
项的子菜单。首先，前面的(父)选项必须是依赖列表中的一部分并且它们中必须有满足下面两个条件的选项：
- 如果父选项为'n'，子选项必须不可见。
- 如果父选项可见，子选项才能可见。
config MODULES
&& bool &Enable loadable module support&
config MODVERSIONS
&& bool &Set version information on all module symbols&
&& depends MODULES
comment &module support disabled&
&& depends !MODULES
MODVERSIONS 直接依赖 MODULES，这就意味着如果MODULES不为'n'，该选项才可见。换句话说，当
MODULES可见时，选项才可见(MODULES的(空)依赖关系也是选项依赖关系的一部分)。
========================================================================================
Kconfig 语法
配置文件描述了菜单选项，每行都是以一关键字开头(除了帮助信息)。下面的关键字结束一菜单选项：
- menuconfig
- choice/endchoice
- menu/endmenu
- if/endif
前5个同样可以用在菜单选项定义的开始。
&& &config& &symbol&
&& &config options&
定义了一配置选项 &symbol& 并且可以接受任何前面介绍的属性。
menuconfig:
&& &menuconfig& &symbol&
&& &config options&
此关键字和前面的关键字很相似，但它在前面的基础上要求所有的子选项作为独立的行显示。(This is
similar to the simple config entry above, but it also gives a hint to front
ends, that all suboptions should be displayed as a separate list of options.)
&& &choice&
&& &choice options&
&& &choice block&
&& &endchoice&
该关键字定义了一组选择项，并且选项可以是前面描述的任何属性。尽管boolean只允许选择一个配置选项，
tristate可以抒多个配置选项设为'm'，但选项只能是boolean或tristate类型。这可以在一个硬件有多
个驱动的情况下使用，最终只有一个驱动被编译进/加载到内核，，但所有的驱动都可以编译成模块。
选项可以接受的另一个选项是&optional&，这样选项就被设置为'n'，没有被选中的。
&& &comment& &prompt&
&& &comment options&
这里定义了在配置过程中显示给用户的注释，该注释还将写进输出文件中。唯一可用的可选项是依赖关系。
&& &menu& &prompt&
&& &menu options&
&& &menu block&
&& &endmenu&
这里定义了一个菜单，详细信息请看前面的&菜单结构&。唯一可用的可选项是依赖关系。
&& &if& &expr&
&& &if block&
&& &endif&
这里定义了if结构。依赖关系&expr&被加到所有在if ... endif 中的菜单选项中。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：200110次
积分：1993
积分：1993
排名：第15700名
原创：12篇
转载：48篇
评论：19条
(1)(1)(8)(4)(3)(8)(1)(2)(11)(1)(10)(8)(2)