一 总体分析
vivi完全套用了Linux kernel的架构，其中工程管理和配置部分直接copy Linux kernel，只做了少量的修改。特别是配置部分，按照如下分类：
文本配置：[scripts/Configure]，只修改了目标的名称，也就是说把Linux kernel换成了vivi，核心的东西没有动。
图形配置：[scripts/Menuconfig]，只修改了目标名称，增加了公司logo，其他没有变化。
所以说，vivi的成功直接源于Linux kernel。而且，从vivi的成功，可以得出结论，学习首先需要临摹，临摹好的软件架构，借用现成的部分，然后写出自己核心的部分。
二 scripts脚本解析
由于图形配置我还不太熟悉，所以重点分析文本配置部分和如果利用Linux kernel来构建自己的bootloader部分。通过该脚本的分析，也可以弄清楚autoconf.h是如何获得的。
1 -->
如果执行make [oldconfig | config]，即在文本模式下进行配置。顶层Makefile下有如下执行命令：$(CONFIG_SHELL) scripts/Configure -d arch/config.in，也就是说要执行[scripts/Configure]这个脚本，顺理成章，下面就是研究这个脚本了。
2 -->
配置的最终结果是生成[.config] [include/autoconf.h]。所以第一步，先定义两个临时的文件，完成后再转化为两个目标的文件即可。使用两个宏就是定义了两个临时文件，都是用来存储配置的结果。CONFIG最终生成的默认的配置文件.config，CONFIG_H最终生成include/autoconf.h。要理解一下，在整个处理过程中，有三种格式的配置文件：一种是原始的（对用户比较清晰的）说明文档，比如arch/defconfig，具体可以查看该文件；第二种是中间配置依赖文档，这是用于配置过程的，你可以查看一下arch/config.in这个文件，发现有许多依赖配置的部分，例如：
|
if [ "$CONFIG_SA1100_EXILIEN102" = "y" ]; then
bool ' Support 16M ROM/RAM' CONFIG_SA1100_EXILIEN102_16M
bool ' Support 32M ROM/RAM' CONFIG_SA1100_EXILIEN102_32M
bool ' Down memory clock' CONFIG_SA1100_EXILIEN102_HALFMEMCLK
fi
|
也就是说，配置采用了类似于C预处理宏的定义方式，不过还是有些直观。那么就需要从第一种原始的文档转换成该配置能够识别的形式，这一部分工作是有sed语句完成的，下面详细分析。转换完成之后，也就是第二种文档的格式了，举例如下：
|
#
# System Type
#
CONFIG_ARCH_SA1100=n
CONFIG_ARCH_PXA250=n
CONFIG_ARCH_S3C2400=n
CONFIG_ARCH_S3C2410=y
|
其实也就是把# CONFIG_MEMORY_RAM_TEST is not set类似的语句转换成了CONFIG_MEMORY_RAM_TEST=n的形式。第三种格式则是我们熟悉的C语言头文件了。这个是在通过 config.in为入口的一系列脚本在执行过程中生成的。
理解了这三种文档格式，就很容易理解过程了。下面进行具体分析。
# 定义临时文件
CONFIG=.tmpconfig
CONFIG_H=.tmpconfig.h
# 下面是自定义一个信号处理机制，即在捕获信号1和信号2时，执行命令rm -f $CONFIG $CONFIG_H ;
# exit 1，也就是删除这两个中间文件，然后退出。这个是为了防止在执行过程中被打断，而造成两个
# 中间文件仍存在的情况。处理得还是比较巧妙。
trap "rm -f $CONFIG $CONFIG_H ; exit 1" 1 2
# 下面两段就是利用>和>>的特点，先生成一个空白的文件，加入自定义的文件头，为后面添加配置选项做好
# 准备。第一段的结果就是生成了$CONFIG文件，文件内容为
# #
# # Automatically generated make config: don't edit
# #
#
#
# Make sure we start out with a clean slate.
#
echo "#" > $CONFIG
echo "# Automatically generated make config: don't edit" >> $CONFIG
echo "#" >> $CONFIG
echo "/*" > $CONFIG_H
echo " * Automatically generated C config: don't edit" >> $CONFIG_H
echo " */" >> $CONFIG_H
echo "#define AUTOCONF_INCLUDED" >> $CONFIG_H
# 利用一个变量来区分已经有默认值和无默认值两种操作。当指定-d时，读取脚本内容如果传递了参数，那么
# 就不用从键盘上输入选项了。这样可以利用默认的配置文件实现全自动化的配置。这在u-boot、Linux
# kernel、vivi中都采用了这种机制。
DEFAULT=""
if [ "$1" = "-d" ] ; then
DEFAULT="-d"
shift # 标识参数向左移动一位，原来的$2就成为了$1，供下面使用
fi
# 第一个要读取的config.in，如果指定了读取文件，则先读取指定的文件。
CONFIG_IN=./config.in
if [ "$1" != "" ] ; then
CONFIG_IN=$1
fi
# 默认的配置文件，按照优先级，如果存在[.config]，则先读取它，如果没有则读取arch/defconfig。
DEFAULTS=arch/defconfig
if [ -f .config ]; then
DEFAULTS=.config
fi
# 处理默认的配置文件，将一类文档转化为二类文档格式，供CONFIG_IN脚本执行使用
if [ -f $DEFAULTS ]; then
echo "#"
echo "# Using defaults found in" $DEFAULTS
echo "#"
. $DEFAULTS
# 这句sed的用法是核心，使用了sed带反斜杠的圆括号的用法。's///'允许在规则表达式中定义区域，然后
# 可以在替换字符串中引用这些特定区域。在使用之前，你首先得编写一个规则表达式，其中区域部分用\(区
# 域*\)标识，所以下面的语句就不难理解了。$$表示进程号，关于这个临时文件的名字，倒不必深究。
sed -e 's/# \(CONFIG_[^ ]*\) is not.*/\1=n/' <$DEFAULTS >.config-is-not.$$
. .config-is-not.$$
rm .config-is-not.$$
else
echo "#"
echo "# No defaults found"
echo "#"
fi
# 执行配置文件，这才是核心部分。通过上面. .config-is-not.$$使得二类文档定义的宏生效
# 那么以CONFIG_IN为入口，执行具体的命令，在执行每条处理的时候，都会将结果按照格式写入
# CONFIG、CONFIG_H两个文件，为最终生成.config和include/autoconf.h做好准备。关于
# 具体的命令部分，在脚本中是以函数的形式提供的，就在这些主要流程代码的前面，包括comment、
# bool等等，这些可以在后面分析。明白了这个，你可以很容易添加自己的配置内容，也可以利用
# 这个配置脚本，完成自己的工程的配置。
# 注意，在这个脚本执行完成后，CONFIG和CONFIG_H已经完成了，不过现在的存在名称仍然是前面
# 定义的.tmpconfig和.tmpconfig.h。还没有最终得到想要的文件。
. $CONFIG_IN
# 处理.config。首先删除原有的.config.old，如果存在.config，那么就把.config更改为
# .config.old，否则的话，直接完成最终想要得到的两个文件.config和include/autoconf.h
# 到这里，也就得到了最终生成的include/autoconf.h。可以为后面的工程编译提供了。
rm -f .config.old
if [ -f .config ]; then
mv .config .config.old
fi
mv .tmpconfig .config
mv .tmpconfig.h include/autoconf.h
# 最后打印一下结束信息
echo
echo "*** End of vivi configuration."
echo "*** Check the top-level Makefile for additional configuration."
echo "*** Next, you must run 'make'."
echo
exit 0
注意的一点是，第一个读取的是[arch/config.in]，采用递归的方式。如果要纳入下一层的读取文件，只需要用“source 文件名”，这样就实现了独立性和通信联系。source也是在Configure里面实现的。
三 实践
我尝试从Linux-2.4.27 kernel中，复制出scripts文件夹，经过的处理主要有两处。一处是arch下没有区分arm，x86，而是只针对arm系列，所以中间一层的目录就取消了。那么脚本中arch/$(ARCH)/config.in就应该改为arch/config.in。另外一处是生成的头文件的路径 include/linux/autoconf.h，现在没有必要用linux这个文件层次，所以就简化为include/autoconf.h。其他的改动就只限于注释名称了，比如注释中把Linux kernel改为vivi。就这样，由此可见该scripts完成的配置机制的可移植性。完全可以用这个架构，借用这种配置方法，完成自己的 bootloader的配置处理机制。另外，Linux kernel还提供了一种模块的操作，代号为M，但是在vivi中是用不到的，可以不去管，也可以把相应的三元组处理部分去掉。
config.in是构建自己的配置内容的文件，它分散于子文件夹中，主要是利用Scripts下的shell脚本提供的命令来完成的。如果分析完成脚本的命令（子函数），构建配置内容（包括添加更改删除配置选项）都可以很方便的完成。我加入了几个配置选项，已经成功。具体代码就不必说了，简单的把用到的几个命令解释一下：
1 mainmenu_name
mainmenu_option
endmenu
这三个函数都是空函数，为了增强可读性而建立的，同时也为了调试方便。在调试的时候，可以把脚本的set的选项中增加-x，这样就可以看清脚本每一步执行的输出内容了。
2 help
帮助信息。它读取[Documentation/Configure.help]中搜寻匹配选项。当然，该帮助文档必须符合一定的格式，关于文本的处理，脚本中使用sed来完成的。
3 comment
用来打印信息。它主要完成三个方面的工作，一是将信息输出到屏幕上，二是按照格式写入.config，三是按照格式写入[include/autoconf.h]。
4 define_bool
就是完成一个布尔类型的宏定义，也就是实现C头文件中的宏定义开关。define_bool实际工作是由define_tristate来完成的。原来 Linux内核选项中有三种方式[Y/N/M]。Y表示打开配置开关，N表示关闭此开关，M表示编译成模块。tristate就是“三态”的意思，现在用到的是两态，也就是twostate。
5 bool
读取键盘输入，完成相应的处理工作。面向的对象当然也是二值处理的。下面还提供了tristate来处理三值处理。不过vivi只用到了bool，还没有用到tristate。
下面看下实例：
mainmenu_name "Linux Kernel Configuration" //调试使用，增强可读性
mainmenu_option next_comment //调试使用，增强可读性，这里用next_comment表示下个主选项
comment 'System Type' //主选项System Type
choice 'ARM system type' \ //表示按下Enter，可以有四个可以选择的选项（图形模式）
//文本模式，则顺序选择
"SA1100-based CONFIG_ARCH_SA1100 \
PXA250/210-based CONFIG_ARCH_PXA250 \
S3C2400-based CONFIG_ARCH_S3C2400 \
S3C2410-based CONFIG_ARCH_S3C2410"
mainmenu_option next_comment //表示进入下个主选项
comment 'General setup'
bool 'Define TEXT Address' CONFIG_VIVI_ADDR //都是子选项的内容
hex 'vivi base address' CONFIG_VIVI_TEXTADDR 0
bool 'support reset handler' CONFIG_RESET_HANDLING
endmenu
source lib/priv_data/Config.in //执行子配置文件
source drivers/serial/Config.in
source drivers/mtd/Config.in
source lib/Config_cmd.in
可见，你要增加某个主选项和子选项的模式就是：
mainmenu_option next_comment
comment "example"
bool "Open the debug switch" CONFIG_DEBUG_SWITCH
bool "Support tftp download" CONFIG_TFTP
endmenu
如果你增加子功能文件夹，那么只需要在该文件夹下建立一个config.in文件，然后利用source联入目录的链就可以了。所以，利用内核的配置脚本实现交互式配置是非常方便的。
四 总结
现在从流程上已经非常清楚了，但是对具体的shell函数的实现没有过多的分析，只是“拿来”就用了。好的程序是易读性强，而且稳定可靠（但是你要明白一个同样的道理，Unix是简单的，但是你必须有足够的能力来理解这种简单。）。学习这种架构，利用这种配置模式，可以站在这个高度上，将这些为我所用。
