【转】vivi开发笔记（四）：配置机制分析

文章说明：calmarrow（lqm）原创 文章引自：http://piaoxiang.cublog.cn

 

一 总体分析

 

    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是简单的，但是你必须有足够的能力来理解这种简单。）。学习这种架构，利用这种配置模式，可以站在这个高度上，将这些为我所用。