跳至主要内容

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

评论

发表评论

此博客中的热门博文

【转】AMBA、AHB、APB总线简介

AMBA 简介 随着深亚微米工艺技术日益成熟，集成电路芯片的规模越来越大。数字IC从基于时序驱动的设计方法，发展到基于IP复用的设计方法，并在SOC设计中得到了广泛应用。在基于IP复用的SoC设计中，片上总线设计是最关键的问题。为此，业界出现了很多片上总线标准。其中，由ARM公司推出的AMBA片上总线受到了广大IP开发商和SoC系统集成者的青睐，已成为一种流行的工业标准片上结构。AMBA规范主要包括了AHB(Advanced High performance Bus)系统总线和APB(Advanced Peripheral Bus)外围总线。   AMBA 片上总线        AMBA 2.0 规范包括四个部分：AHB、ASB、APB和Test Methodology。AHB的相互连接采用了传统的带有主模块和从模块的共享总线，接口与互连功能分离，这对芯片上模块之间的互连具有重要意义。AMBA已不仅是一种总线，更是一种带有接口模块的互连体系。下面将简要介绍比较重要的AHB和APB总线。 基于 AMBA 的片上系统        一个典型的基于AMBA总线的系统框图如图３所示。        大多数挂在总线上的模块(包括处理器)只是单一属性的功能模块：主模块或者从模块。主模块是向从模块发出读写操作的模块，如CPU，DSP等；从模块是接受命令并做出反应的模块，如片上的RAM，AHB／APB 桥等。另外，还有一些模块同时具有两种属性，例如直接存储器存取(DMA)在被编程时是从模块，但在系统读传输数据时必须是主模块。如果总线上存在多个主模块，就需要仲裁器来决定如何控制各种主模块对总线的访问。虽然仲裁规范是AMBA总线规范中的一部分，但具体使用的算法由RTL设计工程师决定，其中两个最常用的算法是固定优先级算法和循环制算法。AHB总线上最多可以有16个主模块和任意多个从模块，如果主模块数目大于16，则需再加一层结构(具体参阅ARM公司推出的Multi-layer AHB规范)。APB 桥既是APB总线上唯一的主模块，也是AHB系统总线上的从模块。其主要功能是锁存来自AHB系统总...
发表评论
阅读全文

【转】VxWorks入门

1．VxWorks开发方式：交叉开发，即将开发分为主机（host）和目标机（target）两部分。 类似于dos下C语言程序的开发。 合并开发的优点：简单 缺点：资源消耗量大，CPU支持，非标准体系的支持 host (Tornado) target(vxWork) 小程序模块 vxWorks实际采用开发模式 Tornado提供：编辑，编译，调试，性能分析工具，是vxWorks的开发工具 vxWorks：面向对象可以剪裁的实际运行操作系统 2.vxWorks启动方式 <1>Rom方式 (vxWork_rom) vxWorks直接烧入rom <2>Rom引导方式（bootrom+vxWorks） 其中bootrom烧入rom，vxWorks可以通过从串口，网口，硬盘，flash等下载！这里的bootrom不是开发环境中的bootable，在开发环境里bootable指的是vxWorks，downloadable指application 3.调试 <1>attachs/20060907_164540_564.rar 用来在多任务调试时将调试对象绑定到某个任务 <2>任务级调试（attachs/20060907_164540_564.rar taskName） 单个任务的调试不会影响到其他任务的运行，主要用来调用户的应用程序。 全局断点：在调另一任务或本任务时，系统运行本任务断点，则停下。各任务要配合使用。 任务断点：调本任务时，系统运行到本任务断点，则停下。如果没有attachs/20060907_164540_564.rar到本任务，不起作用。 一次性断点：跑到一次之后自动删除。 <3>系统级调试(attachs/20060907_164540_564.rar system) 把所有task和系统core、中断看成一个整体，可用于调试系统和中断。对中断调试，如果不是系统级调试，无论是那种断点都不起作用 ！wdbAgent不在调试范围内，当任务级调试时工作在中断方式，系统级调试工作在轮询方式。 ！可是使用命令行方式的调试，参看crossWind教程。 4.调度 优先级调度（无条件） 时间片：同优先级，如果时间片没有打开，任务采取先到先运行，运行完毕在交出cpu，如果打开，则轮流使用cpu。 ！死循环使比它...
发表评论
阅读全文

【转】C++/CLI程序进程之间的通讯

　现在，把大型软件项目分解为一些相交互的小程序似乎变得越来越普遍，程序各部分之间的通讯可使用某种类型的通讯协议，这些程序可能运行在不同的机器上、不同的操作系统中、以不同的语言编写，但也有可能只在同一台机器上，实际上，这些程序可看成是同一程序中的不同线程。而本文主要讨论C++/CLI程序间的通讯，当然，在此是讨论进程间通讯，而不是网络通讯。 　　 简介 　　试想一个包含数据库查询功能的应用，通常有一个被称为服务端的程序，等待另一个被称为客户端程序发送请求，当接收到请求时，服务端执行相应功能，并把结果（或者错误信息）返回给客户端。在许多情况中，有着多个客户端，所有的请求都会在同一时间发送到同一服务端，这就要求服务端程序要更加高级、完善。 　　在某些针对此任务的环境中，服务端程序可能只是众多程序中的一个程序，其他可能也是服务端或者客户端程序，实际上，如果我们的数据库服务端需要访问不存在于本机的文件，那么它就可能成为其他某个文件服务器的一个客户端。一个程序中可能会有一个服务线程及一个或多个客户线程，因此，我们需小心使用客户端及服务端这个术语，虽然它们表达了近似的抽象含义，但在具体实现上却大不相同。从一般的观点来看，客户端即为服务端所提供服务的"消费者"，而服务端也能成为其他某些服务的客户端。 　　 服务端套接字 　　让我们从一个具体有代表性的服务端程序开始（请看例1）,此程序等待客户端发送一对整数，把它们相加之后返回结果给客户端。 　　例1： using namespace System; using namespace System::IO; using namespace System::Net; using namespace System::Net::Sockets; int main(array<String^>^ argv) { if (argv->Length != 1) { Console::WriteLine("Usage: Server port"); Environment::Exit(1); } int port = 0; try { port = Int32::Parse(argv[0]); } catch (FormatException^ e) { Console::Wri...
1 条评论
阅读全文