|
- UID
- 872238
|
"config" 关键字定义新的配置选项，之后的几行定义了该配置选项的属性。配置选项的属性包括类型、数据范围、输入提示、依赖关系（及反向依赖关系）、帮助信息和默认值等。
每个配置选项都必须制定类型，类型包括bool、tristate、string、hex 和 int，其中 tristate 和string 是两种基本的类型，其他类型都基于这两种基本类型。类型定义后可以紧跟输入提示，下面的两段脚本是等价的。
脚本1： bool "Networking support"脚本2： bool prompt "Networking support"输入提示的一般格式的如下所示：prompt <prompt> [if <expr>]其中可选的 if 用来表示该提示的依赖关系。
默认值的格式如下所示： default <expr> [if <expr>]一般配置选项可以存在任意多个默认值，这种情况下，只有第一个被定义的值是可用的。如果用户不设置对应的选项，配置选项的值就是默认值。
依赖关系的格式如下所示：depends on （或者 requires） <expr>如果定义了多个依赖关系，他们之间用 “&&”间隔。依赖关系也可以应用到该菜单中所有的其他选项中（这些选项同样可接受 if 表达式），下面的两端段脚本是等价的。
脚本1： bool "foo" if BAR default y if BAR脚本2： depends on BAR bool "foo" default y反向依赖关系的格式如下所示：select <symbol> [if <expr>] 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> <symbol> '！=' <symbol> ' （ ' <expr> ' ） ' ' ！ ' <expr> <expr> '&&' <expr> <expr> ' || ' <expr>也就是说 expr 是由 symbol 、两个 symbol 相等、两个symbol 不等以及 expr 的赋值、非、与、或运算构成。而 symbol 分为两类，一类是由菜单入口定义配置选项定义的非常数 symbol，另一类是作为 expr 组成部分的常数 symbol.数据范围的格式如下：rang <symbol> <symbol> [if <expr>]为 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 <choice opetions> <choice block> 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 |
|
