linux启动分析
- u-boot-1.1.6
- u-boot配制分析:
- //Makefile
- make xxx_config ---->
- /*sbc2410x_config: unconfig
- @$(MKCONFIG) $(@:_config=) arm arm920t sbc2410x NULL s3c24x0*/
- @$(MKCONFIG) --->执行当前目录下的mkconfig
- //mkconfig
- [ $# -lt 4 ] && exit 1
- [ $# -gt 6 ] && exit 1 //判断传入的参数的个数是否正确
- cd ./include
- rm -f asm
- ln -s asm-$2 asm = ln -s asm-arm arm //建立软链接
- echo "ARCH = $2" > config.mk
- echo "CPU = $3" >> config.mk
- echo "BOARD = $4" >> config.mk //将配制文件写入config.mk中
- u-boot启动分析：
- //cpu/arm920t/start.S
- .globl _start
- _start: b reset --->
- reset:
- mrs r0,cpsr
- bic r0,r0,#0x1f
- orr r0,r0,#0xd3
- msr cpsr,r0 //设置CPU为管理模式
- ldr r0, =pWTCON
- mov r1, #0x0
- str r1, [r0] //关看门狗
- mov r1, #0xffffffff
- ldr r0, =INTMSK
- str r1, [r0]
- #if defined(CONFIG_S3C2410)
- ldr r1, =0x3ff
- ldr r0, =INTSUBMSK
- str r1, [r0]
- #endif //关中断
- ........
- ldr pc, _start_armboot
- _start_armboot: .word start_armboot ---> //跳入C程序入口
- //lib_arm/board.c
- start_armboot(); --->
- //函数指针，进行一系列的初始化
- for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
- if ((*init_fnc_ptr)() != 0) {
- hang ();
- }
- }
- //进入死循环
- for (;;) {
- main_loop (); --->
- }
- //common/main.c
- main_loop(); --->
- s = getenv ("bootcmd");
- run_command (s, 0); --->
- parse_line();
- find_cmd();
- //函数调用，执行相应的命令
- if ((cmdtp->cmd) (cmdtp, flag, argc, argv) != 0);
- //调用的函数为宏所定义的
- #define Struct_Section __attribute__ ((unused,section (".u_boot_cmd")))
- #define U_BOOT_CMD(name,maxargs,rep,cmd,usage,help) \
- cmd_tbl_t __u_boot_cmd_##name Struct_Section = {#name, maxargs, rep, cmd, usage}
- |
- | //board/smdk2410/u-boot.lds
- | __u_boot_cmd_start = .;
- ---------------> .u_boot_cmd : { *(.u_boot_cmd) }
- __u_boot_cmd_end = .;
- //如
- U_BOOT_CMD(nboot, 4, 1, do_nandboot,
- "nboot - boot from NAND device\n",
- "[partition] | [[[loadAddr] dev] offset]\n"); --->
- do_nandboot();//做一些事
- //启动 /command/cmd_bootm.c
- U_BOOT_CMD(bootm, CFG_MAXARGS,1,do_bootm,"XXXX"); --->
- do_bootm(); -->
- do_bootm_linux(); --->
- /*把参数保存到内存中*/
- setup_start_tag (bd);
- setup_serial_tag (¶ms);
- setup_revision_tag (¶ms);
- setup_memory_tags (bd);
- setup_commandline_tag (bd, commandline);
- setup_videolfb_tag ((gd_t *) gd);
- setup_end_tag (bd);
- ----> theKernel = (void (*)(int, int, uint))ntohl(hdr->ih_ep);
- theKernel (0, bd->bi_arch_number, bd->bi_boot_params); //内核起动
- /******************************************************************************************************************/
- linux-2.6.32
- //编译内核时的步骤：
- (1),配制内核，make xxx_config 即/arch/arm/configs/XXX_config 生成 .config
- .config生成|（1），include/config/auto.conf ---> //给子目录的Makefile用
- |（2），include/linux/autoconf.h ---> //给C代码用
- (2),make uImage
- 顶Makefile里包含了/arch/arm/Makefile（include $(srctree)/arch/$(SRCARCH)/Makefile）
- ///arch/arm/Makefile
- # Convert bzImage to zImage
- bzImage: zImage
- zImage Image xipImage bootpImage uImage: vmlinux
- $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@
- (3),make
- 当make时，
- all: vmlinux
- //把这些文件编译成vmlinux.o
- vmlinux: $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) vmlinux.o $(kallsyms.o) FORCE
- SRCARCH := $(ARCH)
- ARCH ?= arm
- ①----->vmlinux-lds := arch/$(SRCARCH)/kernel/vmlinux.lds
- = arch/arm/kernel/vmlinux.lds
- //在/arch/arm/Makefile里定义
- head-y := arch/arm/kernel/head$(MMUEXT).o arch/arm/kernel/init_task.o
- = arch/arm/kernel/head.o arch/arm/kernel/init_task.o $(MMUEXT)为空
- //在顶层目录的Makefile
- init-y := init/ （init/下的全部文件）
- ②----->vmlinux-init := $(head-y) $(init-y)
- core-y += kernel/ mm/ fs/ ipc/ security/ crypto/ block/
- core-y := $(patsubst %/, %/built-in.o, $(core-y))
- = core/built-in.o 即core/目录下的文件全部编译为built-in.o
- drivers-y := $(patsubst %/, %/built-in.o, $(drivers-y))
- = drivers/built-in.o
- net-y := $(patsubst %/, %/built-in.o, $(net-y))
- = net/built-in.o
- ③----->vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y)
- /*Makefile的结果总结：
- （1）配置文件.config中定义了一系列的变量，Makefile将结合它们来决定哪些文件被编进内核，哪些
- 文件被编成模块。涉及哪些文件目录
- （2）顶层Makefile和arch/$(ARCH)/Makefile决定根目录下哪些子目录，arch/$(ARCH)目录下哪些文件和
- 目录将被编进内核
- （3）最后，各级子目录下的Makefile决定所在目录下哪些文件将被编进内核，哪些文件将被编成模块（驱动）
- 进入哪些子目录继续调用它们的Makefile
- （4）顶层Makefile和arch/$(ARCH)/Makefile设置了可以影响所有文件的编译，连接选项：CFLAGS. AFLAGS...
- （5）顶层Makefile按照一定的顺序组织文件，根据连接脚本arch/$(ARCH)/kernel/vmlinux.lds生成内核映像
- 文件vmlinux
- */
- //内核启动流程：
- 如上面可知，/arch/arm/kernel/head.S文件是内核启动的第一个文件
- ENTRY(stext)
- setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ 确保进入管理（SVC）模式
- @ 禁止中断
- mrc p15, 0, r9, c0, c0 @ 读取CPU ID，存入R9寄存器
- bl __lookup_processor_type @ r5=返回值 r9=输入参数，调用函数
- movs r10, r5 @ 如果不支持当前CPU，返回R5=0
- beq __error_p @ 如果R5=0， 则打印错误
- bl __lookup_machine_type @ 调用函数，返回值r5=machinfo
- movs r8, r5 @ 如果不支持当前开发板，返回r5=0
- beq __error_a @ 如果R5=0，则打印错误
- bl __vet_atags
- bl __create_page_tables //arch/arm/kernel/head-common.S
- __switch_data -----> __mmap_switched -----> start_kernel //起动内核
- //__lookup_processor_type，__lookup_machine_type 函数在arch/arm/kernel/head-common.S中定义
- __lookup_processor_type:
- //arch\arm\kernel\vmlinux-lds.S arch\arm\kernel\proc-arm920.S
- __proc_info_begin = .; .section ".proc.info.init", #alloc, #execinstr
- *(.proc.info.init) -----> .type __arm920_proc_info,#object
- __proc_info_end = .; ------ __arm920_proc_info:
- | .long 0x41009200 //CPU id,cpu_val
- | .long 0xff00fff0 //cpu_mask
- | .....
- | //arch/arm/include/asm/procinfo.h
- | struct proc_info_list {
- | unsigned int cpu_val;
- | unsigned int cpu_mask;
- | unsigned long __cpu_mm_mmu_flags; /* used by head.S */
- | unsigned long __cpu_io_mmu_flags; /* used by head.S */
- | unsigned long __cpu_flush; /* used by head.S */
- | const char *arch_name;
- |------> const char *elf_name;
- unsigned int elf_hwcap;
- const char *cpu_name;
- struct processor *proc;
- struct cpu_tlb_fns *tlb;
- struct cpu_user_fns *user;
- struct cpu_cache_fns *cache;
- };
- __lookup_machine_type:
- //arch\arm\kernel\vmlinux-lds.S arch/arm/include/asm/mach/arch.h
- __arch_info_begin = .; #define MACHINE_START(_type,_name) \
- *(.arch.info.init) -------> static const struct machine_desc __mach_desc_##_type \
- __arch_info_end = .; __used \
- -------- __attribute__((__section__(".arch.info.init"))) = { \
- | .nr = MACH_TYPE_##_type, \
- | .name = _name,
- | #define MACHINE_END \
- | };
- |----|
- |
- //linux/arch/arm/mach-s3c2410/mach-smdk2410.c
- MACHINE_START(SMDK2410, "SMDK2410") static const struct machine_desc __mach_desc_SMDK2410
- /* @TODO: request a new identifier and switch*/ __used
- /* to SMDK2410 */ __attribute__((__section__(".arch.info.init"))) = {
- /* Maintainer: Jonas Dietsche */ .nr = MACH_TYPE_SMDK2410,
- .phys_io = S3C2410_PA_UART, -------> .name = "SMDK2410",
- .io_pg_offst = (((u32)S3C24XX_VA_UART) .......
- >> 18) & 0xfffc, .......
- .boot_params = S3C2410_SDRAM_PA + 0x100, };
- .map_io = smdk2410_map_io,
- .init_irq = s3c24xx_init_irq,
- .init_machine = smdk2410_init,
- .timer = &s3c24xx_timer,
- MACHINE_END
- //内核C程序起动分析：
- //在汇编程序/arch/arm/kernel/head-common.S中调用 start_kernel。
- //init/main.c
- start_kernel --->
- printk(KERN_NOTICE "%s", linux_banner);//打印内核版本信息
- setup_arch(&command_line); --->
- //进行处理器相关的一些设置
- setup_processor(); --->
- //目的是获得该处理器的proc_info_list结构
- lookup_processor_type();--->
- __lookup_processor_type;//arch/arm/kernel/head-common.S
- setup_machine(); --->
- //获得开发板的machine_desc结构
- lookup_machine_type(); --->
- __lookup_machine_type;//arch/arm/kernel/head-common.S
- if (mdesc->boot_params){//用来确定bootloader传入的启动参数的地址
- //mach-smdk2410.c ---> .boot_params = S3C2410_SDRAM_PA + 0x100 = 0x30000100
- tags = phys_to_virt(mdesc->boot_params);
- }
- //解释每一个tags
- parse_tags(tags); --->
- parse_tag(t); --->
- //处理每一个tag，调用每一种处理函数
- t->parse(tag); --->
- //在/arch/arm/kernel/setup.c里定义
- __tagtable(BP_TAG_MEMORY, parse_tag_mem);
- __tagtable(BP_TAG_COMMAND_LINE, parse_tag_cmdline);
- .....
- parse_cmdline(cmdline_p, from); //对命令行进行一些先期的处理
- paging_init(struct machine_desc *mdesc); --->//重新初始化页表
- devicemaps_init(struct machine_desc *mdesc); --->
- if (mdesc->map_io){
- mdesc->map_io();--->
- //arch/arm/mach-s3c2410/mach-smdk2410.c
- smdk2410_map_io();//设备串口相关的东西
- }
- parse_early_param();
- parse_args(); --->
- parse_one() --->
- unknown_bootoption(); --->
- obsolete_checksetup(); --->
- p->setup_func(line + n); --->
- __setup(str, fn);//include/init/init.h
- console_init(); --->
- console_initcall();
- rest_init(); --->
- kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND); --->
- //继续初始化内核，并创建init进程
- kernel_init(); --->
- init_post(); --->
- //打开控制终端
- sys_open((const char __user *) "/dev/console", O_RDWR, 0);
- (void) sys_dup(0);
- (void) sys_dup(0);
- run_init_process("/XXX/init"); //开跑第一个应用程序
- kernel_thread(kthreadd, NULL, CLONE_FS | CLONE_FILES);
- /***************************************************************************************************************/
第一个应用程序：
//system/code/init/init.c
目前Linux有很多通讯机制可以在用户空间和内核空间之间交互，
例如设备驱动文件（位于/dev目录中）、内存文件（/proc、/sys目录等）。
了解Linux的同学都应该知道Linux的重要特征之一就是一切都是以文件的形式存在的，
例如，一个设备通常与一个或多个设备文件对应。这些与内核空间交互的文件都在用户空间，
所以在Linux内核装载完，需要首先建立这些文件所在的目录。
而完成这些工作的程序就是本文要介绍的init。Init是一个命令行程序。
其主要工作之一就是建立这些与内核空间交互的文件所在的目录。当Linux内核加载完后，
要做的第一件事就是调用init程序，也就是说，init是用户空间执行的第一个程序。
在分析init的核心代码之前，还需要初步了解init除了建立一些目录外，还做了如下的工作
1. 初始化属性
2. 处理配置文件的命令（主要是init.rc文件），包括处理各种Action。
3. 性能分析（使用bootchart工具）。
4. 无限循环执行command（启动其他的进程）。
尽管init完成的工作不算很多，不过代码还是非常复杂的。Init程序并不是由一个源代码文件组成的，而是由一组源代码文件的目标文件链接而成的。这些文件位于如下的目录。
<Android源代码本目录>/system/core/init
其中init.c是init的主文件，现在打开该文件，看看其中的内容。由于init是命令行程序，所以分析init.c首先应从main函数开始，现在好到main函数，代码如下：
- int main(int argc, char **argv)
- {
- int fd_count = 0;
- struct pollfd ufds[4];
- char *tmpdev;
- char* debuggable;
- char tmp[32];
- int property_set_fd_init = 0;
- int signal_fd_init = 0;
- int keychord_fd_init = 0;
- if (!strcmp(basename(argv[0]), "ueventd"))
- return ueventd_main(argc, argv);
- /* clear the umask */
- umask(0);
- /* Get the basic filesystem setup we need put
- * together in the initramdisk on / and then we'll
- * let the rc file figure out the rest.
- * 下面的代码开始建立各种用户空间的目录，如/dev、/proc、/sys等
- */
- mkdir("/dev", 0755);
- mkdir("/proc", 0755);
- mkdir("/sys", 0755);
- mount("tmpfs", "/dev", "tmpfs", 0, "mode=0755");
- mkdir("/dev/pts", 0755);
- mkdir("/dev/socket", 0755);
- mount("devpts", "/dev/pts", "devpts", 0, NULL);
- mount("proc", "/proc", "proc", 0, NULL);
- mount("sysfs", "/sys", "sysfs", 0, NULL);
- /* We must have some place other than / to create the
- * device nodes for kmsg and null, otherwise we won't
- * be able to remount / read-only later on.
- * Now that tmpfs is mounted on /dev, we can actually
- * talk to the outside world.
- */
- open_devnull_stdio();
- log_init();
- INFO("reading config file\n");// 分析/init.rc文件的内容
- init_parse_config_file("/init.rc");
- /* pull the kernel commandline and ramdisk properties file in */
- import_kernel_cmdline(0);
- get_hardware_name(hardware, &revision);
- snprintf(tmp, sizeof(tmp), "/init.%s.rc", hardware);
- init_parse_config_file(tmp);
- action_for_each_trigger("early-init", action_add_queue_tail);
- queue_builtin_action(wait_for_coldboot_done_action, "wait_for_coldboot_done");
- queue_builtin_action(property_init_action, "property_init");
- queue_builtin_action(keychord_init_action, "keychord_init");
- queue_builtin_action(console_init_action, "console_init");
- queue_builtin_action(set_init_properties_action, "set_init_properties");
- /* execute all the boot actions to get us started */
- action_for_each_trigger("init", action_add_queue_tail);
- action_for_each_trigger("early-fs", action_add_queue_tail);
- action_for_each_trigger("fs", action_add_queue_tail);
- action_for_each_trigger("post-fs", action_add_queue_tail);
- queue_builtin_action(property_service_init_action, "property_service_init");
- queue_builtin_action(signal_init_action, "signal_init");
- queue_builtin_action(check_startup_action, "check_startup");
- /* execute all the boot actions to get us started */
- action_for_each_trigger("early-boot", action_add_queue_tail);
- action_for_each_trigger("boot", action_add_queue_tail);
- /* run all property triggers based on current state of the properties */
- queue_builtin_action(queue_property_triggers_action, "queue_propety_triggers");
- #if BOOTCHART
- queue_builtin_action(bootchart_init_action, "bootchart_init");
- #endif
- // 进入无限循环，建立init的子进程（init是所有进程的父进程）
- for(;;) {
- int nr, i, timeout = -1;
- // 执行命令（子进程对应的命令）
- execute_one_command();
- restart_processes();
- if (!property_set_fd_init && get_property_set_fd() > 0) {
- ufds[fd_count].fd = get_property_set_fd();
- ufds[fd_count].events = POLLIN;
- ufds[fd_count].revents = 0;
- fd_count++;
- property_set_fd_init = 1;
- }
- if (!signal_fd_init && get_signal_fd() > 0) {
- ufds[fd_count].fd = get_signal_fd();
- ufds[fd_count].events = POLLIN;
- ufds[fd_count].revents = 0;
- fd_count++;
- signal_fd_init = 1;
- }
- if (!keychord_fd_init && get_keychord_fd() > 0) {
- ufds[fd_count].fd = get_keychord_fd();
- ufds[fd_count].events = POLLIN;
- ufds[fd_count].revents = 0;
- fd_count++;
- keychord_fd_init = 1;
- }
- if (process_needs_restart) {
- timeout = (process_needs_restart - gettime()) * 1000;
- if (timeout < 0)
- timeout = 0;
- }
- if (!action_queue_empty() || cur_action)
- timeout = 0;
- #if BOOTCHART
- if (bootchart_count > 0) {
- if (timeout < 0 || timeout > BOOTCHART_POLLING_MS)
- timeout = BOOTCHART_POLLING_MS;
- if (bootchart_step() < 0 || --bootchart_count == 0) {
- bootchart_finish();
- bootchart_count = 0;
- }
- }
- #endif
- // 等待下一个命令的提交
- nr = poll(ufds, fd_count, timeout);
- if (nr <= 0)
- continue;
- for (i = 0; i < fd_count; i++) {
- if (ufds[i].revents == POLLIN) {
- if (ufds[i].fd == get_property_set_fd())
- handle_property_set_fd();
- else if (ufds[i].fd == get_keychord_fd())
- handle_keychord();
- else if (ufds[i].fd == get_signal_fd())
- handle_signal();
- }
- }
- }
- return 0;
- }
我们可以看到main函数是非常复杂的，不过我们也不需要每条语句都弄得非常清楚（因为这样弄是非常困难的），通常只需要了解init的主线即可。其实从init的main函数可以看出。Init实际上就分为如下两部分。
1. 初始化（包括建立/dev、/proc等目录、初始化属性、执行init.rc等初始化文件中的action等）。
2. 使用for循环无限循环建立子进程。
第一项工作很好理解。而第二项工作是init中的核心。在Linux系统中init是一切应用空间进程的父进程。所以我们平常在Linux终端执行的命令，并建立进程。实际上都是在这个无限的for循环中完成的。也就是说，在Linux终端执行ps –e 命令后，看到的所有除了init外的其他进程，都是由init负责创建的。而且init也会常驻内容。当然，如果init挂了，Linux系统基本上就崩溃了。
由于init比较复杂，所以本文只分析其中的一部分，在后续文章中将详细分析init的各个核心组成部分。
对于main函数最开始完成的建立目录的工作比较简单，这部分也没什么可以分析的。就是调用了一些普通的API（mkdir）建立一些目录。现在说一些题外话，由于Android的底层源代码（包括init）实际上是属于Linux应用编程领域，所以要想充分理解Android源代码，除了Linux的基本结构要了解外，Linux应用层的API需要熟悉。为了满足这些读者的需要，后续我会写一些关于Linux应用编程的文章。Ok，现在言归正传，接下来分析一个比较重要的部分：配置文件的解析。
这里的配置文件主要指init.rc。读者可以进到Android的shell，会看到根目录有一个init.rc文件。该文件是只读的，即使有了root权限，可以修改该文件也没有。因为我们在根目录看到的文件只是内存文件的镜像。也就是说，android启动后，会将init.rc文件装载到内存。而修改init.rc文件的内容实际上只是修改内存中的init.rc文件的内容。一旦重启android，init.rc文件的内容又会恢复到最初的装载。想彻底修改init.rc文件内容的唯一方式是修改Android的ROM中的内核镜像（boot.img）。其实boot.img名曰内核镜像，不过该文件除了包含完整的Linux内核文件（zImage）外，还包括另外一个镜像文件（ramdisk.img）。ramdisk.img就包含了init.rc文件和init命令。所以只有修改ramdisk.img文件中的init.rc文件，并且重新打包boot.img文件，并刷机，才能彻底修改init.rc文件。如果读者有Android源代码，编译后，就会看到out目录中的相关子目录会生成一个root目录，该目录实际上就是ramdisk.img解压后的内容。会看到有init命令和init.rc文件。在后续的文章中将会讨论具体如何修改init.rc文件，如何刷机。不过这些内容与本文关系不大，所以不做详细的讨论。
现在回到main函数，在创建完目录后，会看到执行了如下3个函数。
property_init();
get_hardware_name(hardware, &revision);
process_kernel_cmdline();
其中property_init主要是为属性分配一些存储空间，该函数并不是核心。不过当我们查看init.rc文件时会发现该文件开始部分用一些import语句导入了其他的配置文件，例如，/init.usb.rc。大多数配置文件都直接使用了确定的文件名，只有如下的代码使用了一个变量（${ro.hardware}）执行了配置文件名的一部分。那么这个变量值是从哪获得的呢？
import /init.${ro.hardware}.rc
首先要了解init.${ro.hardware}.rc配置文件的内容通常与当前的硬件有关。现在我们先来关注get_hardware_name函数，代码如下：
- void get_hardware_name(char *hardware, unsigned int *revision)
- {
- char data[1024];
- int fd, n;
- char *x, *hw, *rev;
- /* Hardware string was provided on kernel command line */
- /* 如果hardware已经有值了，说明hardware通过内核命令行提供，直接返回 */
- if (hardware[0])
- return;
- // 打开/proc/cpuinfo文件
- fd = open("/proc/cpuinfo", O_RDONLY);
- if (fd < 0) return;
- // 读取/proc/cpuinfo文件的内容
- n = read(fd, data, 1023);
- close(fd);
- if (n < 0) return;
- // 从/proc/cpuinfo文件中获取Hardware字段的值
- data[n] = 0;
- hw = strstr(data, "\nHardware");
- rev = strstr(data, "\nRevision");
- if (hw) {// 成功获取Hardware字段的值
- x = strstr(hw, ": ");
- if (x) {
- x += 2;
- n = 0;
- while (*x && !isspace(*x)) {
- hardware[n++] = tolower(*x); // 将Hardware字段的值都转换为小写，并更新hardware参数的值
- // hardware也就是在init.c文件中定义的hardware数组
- x++;
- if (n == 31) break;
- }
- hardware[n] = 0;
- }
- }
- if (rev) {
- x = strstr(rev, ": ");
- if (x) {
- *revision = strtoul(x + 2, 0, 16);
- }
- }
- }
从get_hardware_name方法的代码可以得知，该方法主要用于确定hardware和revision的变量的值。Revision这里先不讨论，只要研究hardware。获取hardware的来源是从Linux内核命令行或/proc/cpuinfo文件中的内容。Linux内核命令行暂且先不讨论（因为很少传递该值），先看看/proc/cpuinfo，该文件是虚拟文件（内存文件），执行cat /proc/cpuinfo命令会看到该文件中的内容，如图1所示。在白框中就是Hardware字段的值。由于该设备是Nexus 7，所以值为grouper。如果程序就到此位置，那么与硬件有关的配置文件名是init.grouper.rc。有Nexus 7的读者会看到在根目录下确实有一个init.grouper.rc文件。说明Nexus 7的原生ROM并没有在其他的地方设置配置文件名，所以配置文件名就是从/proc/cpuinfo文件的Hardware字段中取的值。
在上一篇文章中介绍了init的初始化第一阶段，也就是处理各种属性。在本文将会详细分析init最重要的一环：解析init.rc文件。
init.rc文件并不是普通的配置文件，而是由一种被称为“Android初始化语言”（Android Init Language，这里简称为AIL）的脚本写成的文件。在了解init如何解析init.rc文件之前，先了解AIL非常必要，否则机械地分析init.c及其相关文件的源代码毫无意义。
为了学习AIL，读者可以到自己Android手机的根目录寻找init.rc文件，最好下载到本地以便查看，如果有编译好的Android源代码，在<Android源代码根目录>out/target/product/generic/root目录也可找到init.rc文件。
AIL由如下4部分组成。
1. 动作（Actions）
2. 命令（Commands）
3． 服务（Services）
4. 选项（Options）
这4部分都是面向行的代码，也就是说用回车换行符作为每一条语句的分隔符。而每一行的代码由多个符号（Tokens）表示。可以使用反斜杠转义符在Token中插入空格。双引号可以将多个由空格分隔的Tokens合成一个Tokens。如果一行写不下，可以在行尾加上反斜杠，来连接下一行。也就是说，可以用反斜杠将多行代码连接成一行代码。
AIL的注释与很多Shell脚本一行，以#开头。
AIL在编写时需要分成多个部分（Section），而每一部分的开头需要指定Actions或Services。也就是说，每一个Actions或Services确定一个Section。而所有的Commands和Options只能属于最近定义的Section。如果Commands和Options在第一个Section之前被定义，它们将被忽略。
Actions和Services的名称必须唯一。如果有两个或多个Action或Service拥有同样的名称，那么init在执行它们时将抛出错误，并忽略这些Action和Service。
下面来看看Actions、Services、Commands和Options分别应如何设置。
Actions的语法格式如下：
- on <trigger>
- <command>
- <command>
- <command>
也就是说Actions是以关键字on开头的，然后跟一个触发器，接下来是若干命令。例如，下面就是一个标准的Action
- on boot
- ifup lo
- hostname localhost
- domainname localdomain
其中boot是触发器，下面三行是command
那么init.rc到底支持哪些触发器呢？目前init.rc支持如下5类触发器。
1. boot
这是init执行后第一个被触发Trigger，也就是在 /init.rc被装载之后执行该Trigger
2. <name>=<value>
当属性<name>被设置成<value>时被触发。例如，
on property:vold.decrypt=trigger_reset_main
class_reset main
3. device-added-<path>
当设备节点被添加时触发
4. device-removed-<path>
当设备节点被移除时添加
5. service-exited-<name>
会在一个特定的服务退出时触发
Actions后需要跟若干个命令，这些命令如下：
1. exec <path> [<argument> ]*
创建和执行一个程序（<path>）。在程序完全执行前，init将会阻塞。由于它不是内置命令，应尽量避免使用exec ，它可能会引起init执行超时。
2. export <name> <value>
在全局环境中将 <name>变量的值设为<value>。（这将会被所有在这命令之后运行的进程所继承）
3. ifup <interface>
启动网络接口
4. import <filename>
指定要解析的其他配置文件。常被用于当前配置文件的扩展
5. hostname <name>
设置主机名
6. chdir <directory>
改变工作目录
7. chmod <octal-mode><path>
改变文件的访问权限
8. chown <owner><group> <path>
更改文件的所有者和组
9. chroot <directory>
改变处理根目录
10. class_start<serviceclass>
启动所有指定服务类下的未运行服务。
11 class_stop<serviceclass>
停止指定服务类下的所有已运行的服务。
12. domainname <name>
设置域名
13. insmod <path>
加载<path>指定的驱动模块
14. mkdir <path> [mode][owner] [group]
创建一个目录<path> ，可以选择性地指定mode、owner以及group。如果没有指定，默认的权限为755，并属于root用户和 root组。
15. mount <type> <device> <dir> [<mountoption> ]*
试图在目录<dir>挂载指定的设备。<device> 可以是mtd@name的形式指定一个mtd块设备。<mountoption>包括 "ro"、"rw"、"re
16. setkey
保留，暂时未用
17. setprop <name><value>
将系统属性<name>的值设为<value>。
18. setrlimit <resource> <cur> <max>
设置<resource>的rlimit （资源限制）
19. start <service>
启动指定服务（如果此服务还未运行）。
20．stop<service>
停止指定服务（如果此服务在运行中）。
21. symlink <target> <path>
创建一个指向<path>的软连接<target>。
22. sysclktz <mins_west_of_gmt>
设置系统时钟基准（0代表时钟滴答以格林威治平均时（GMT）为准）
23. trigger <event>
触发一个事件。用于Action排队
24. wait <path> [<timeout> ]
等待一个文件是否存在，当文件存在时立即返回，或到<timeout>指定的超时时间后返回，如果不指定<timeout>，默认超时时间是5秒。
25. write <path> <string> [ <string> ]*
向<path>指定的文件写入一个或多个字符串。
Services （服务）是一个程序，他在初始化时启动，并在退出时重启（可选）。Services （服务）的形式如下：
- service <name> <pathname> [ <argument> ]*
- <option>
- <option>
例如，下面是一个标准的Service用法
- service servicemanager /system/bin/servicemanager
- class core
- user system
- group system
- critical
- onrestart restart zygote
- onrestart restart media
- onrestart restart surfaceflinger
- onrestart restart drm
1. critical
表明这是一个非常重要的服务。如果该服务4分钟内退出大于4次，系统将会重启并进入 Recovery （恢复）模式。
2. disabled
表明这个服务不会同与他同trigger （触发器）下的服务自动启动。该服务必须被明确的按名启动。
3. setenv <name><value>
在进程启动时将环境变量<name>设置为<value>。
4. socket <name><type> <perm> [ <user> [ <group> ] ]
Create a unix domain socketnamed /dev/socket/<name> and pass
its fd to the launchedprocess. <type> must be"dgram", "stream" or "seqpacket".
User and group default to0.
创建一个unix域的名为/dev/socket/<name> 的套接字，并传递它的文件描述符给已启动的进程。<type> 必须是 "dgram","stream" 或"seqpacket"。用户和组默认是0。
5. user <username>
在启动这个服务前改变该服务的用户名。此时默认为 root。
6. group <groupname> [<groupname> ]*
在启动这个服务前改变该服务的组名。除了（必需的）第一个组名，附加的组名通常被用于设置进程的补充组（通过setgroups函数），档案默认是root。
7. oneshot
服务退出时不重启。
8. class <name>
指定一个服务类。所有同一类的服务可以同时启动和停止。如果不通过class选项指定一个类，则默认为"default"类服务。
9. onrestart
当服务重启，执行一个命令（下详）。
现在接着分析一下init是如何解析init.rc的。现在打开system/core/init/init.c文件，找到main函数。在上一篇文章中分析了main函数的前一部分（初始化属性、处理内核命令行等），现在找到init_parse_config_file函数，调用代码如下：
init_parse_config_file("/init.rc");
这个方法主要负责初始化和分析init.rc文件。init_parse_config_file函数在init_parser.c文件中实现，代码如下：
- int init_parse_config_file(const char *fn)
- {
- char *data;
- data = read_file(fn, 0);
- if (!data) return -1;
- /* 实际分析init.rc文件的代码 */
- parse_config(fn, data);
- DUMP();
- return 0;
- }
init_parse_config_file方法开始调用了read_file函数打开了/init.rc文件，并返回了文件的内容（char*类型），然后最核心的函数是parse_config。该函数也在init_parser.c文件中实现，代码如下：
- static void parse_config(const char *fn, char *s)
- {
- struct parse_state state;
- struct listnode import_list;
- struct listnode *node;
- char *args[INIT_PARSER_MAXARGS];
- int nargs;
- nargs = 0;
- state.filename = fn;
- state.line = 0;
- state.ptr = s;
- state.nexttoken = 0;
- state.parse_line = parse_line_no_op;
- list_init(&import_list);
- state.priv = &import_list;
- /* 开始获取每一个token，然后分析这些token，每一个token就是有空格、字表符和回车符分隔的字符串
- */
- for (;;) {
- /* next_token函数相当于词法分析器 */
- switch (next_token(&state)) {
- case T_EOF: /* init.rc文件分析完毕 */
- state.parse_line(&state, 0, 0);
- goto parser_done;
- case T_NEWLINE: /* 分析每一行的命令 */
- /* 下面的代码相当于语法分析器 */
- state.line++;
- if (nargs) {
- int kw = lookup_keyword(args[0]);
- if (kw_is(kw, SECTION)) {
- state.parse_line(&state, 0, 0);
- parse_new_section(&state, kw, nargs, args);
- } else {
- state.parse_line(&state, nargs, args);
- }
- nargs = 0;
- }
- break;
- case T_TEXT: /* 处理每一个token */
- if (nargs < INIT_PARSER_MAXARGS) {
- args[nargs++] = state.text;
- }
- break;
- }
- }
- parser_done:
- /* 最后处理由import导入的初始化文件 */
- list_for_each(node, &import_list) {
- struct import *import = node_to_item(node, struct import, list);
- int ret;
- INFO("importing '%s'", import->filename);
- /* 递归调用 */
- ret = init_parse_config_file(import->filename);
- if (ret)
- ERROR("could not import file '%s' from '%s'\n",
- import->filename, fn);
- }
- }
parse_config方法的代码就比较复杂了，现在先说说该方法的基本处理流程。首先会调用 list_init(&import_list)初始化一个链表，该链表是用于存储通过import语句导入的初始化文件名。然后开始开始在for循环中分析init.rc文件中的每一行代码。最后将init.rc文件分析完后，就会进入parser_done部分，并递归调用init_parse_config_file方法分析通过import导入的初始化文件。
通过分析parse_config方法的原理，感觉也并不是很复杂。不过分析parse_config方法的具体代码，还需要点编译原理的知识（只是概念上的就可以）。在for循环中调用了一个next_token方法不断从init.rc文件中获取token。这里的token，就是一种编程语言的最小单元，也就是不可再分。例如，对于传统的编程语言，if、then等关键字、变量名等标识符都属于一个token。而对于init.rc文件来说，import、on、以及触发器的参数值，都属于一个token。
一个完整的编译器（或解析器）最开始需要进行词法和语法分析，词法分析就是在源代码文件中挑出一个个的Token，也就是说，词法分析器的返回值是Token，而语法分析器的输入就是词法分析器的输出。也就是说，语法分析器需要分析一个个的token，而不是一个个的字符。由于init解析语言很简单，所以就将词法和语法分析器放到了一起。词法分析器就是next_token函数，而语法分析器就是T_NEWLINE分支中的代码。这些就清楚多了。现在先看看next_token函数（在parser.c文件中实现）是如何获取每一个token的。
- int next_token(struct parse_state *state)
- {
- char *x = state->ptr;
- char *s;
- if (state->nexttoken) {
- int t = state->nexttoken;
- state->nexttoken = 0;
- return t;
- }
- /* 在这里开始一个字符一个字符地分析 */
- for (;;) {
- switch (*x) {
- case 0:
- state->ptr = x;
- return T_EOF;
- case '\n':
- x++;
- state->ptr = x;
- return T_NEWLINE;
- case ' ':
- case '\t':
- case '\r':
- x++;
- continue;
- case '#':
- while (*x && (*x != '\n')) x++;
- if (*x == '\n') {
- state->ptr = x+1;
- return T_NEWLINE;
- } else {
- state->ptr = x;
- return T_EOF;
- }
- default:
- goto text;
- }
- }
- textdone:
- state->ptr = x;
- *s = 0;
- return T_TEXT;
- text:
- state->text = s = x;
- textresume:
- for (;;) {
- switch (*x) {
- case 0:
- goto textdone;
- case ' ':
- case '\t':
- case '\r':
- x++;
- goto textdone;
- case '\n':
- state->nexttoken = T_NEWLINE;
- x++;
- goto textdone;
- case '"':
- x++;
- for (;;) {
- switch (*x) {
- case 0:
- /* unterminated quoted thing */
- state->ptr = x;
- return T_EOF;
- case '"':
- x++;
- goto textresume;
- default:
- *s++ = *x++;
- }
- }
- break;
- case '\\':
- x++;
- switch (*x) {
- case 0:
- goto textdone;
- case 'n':
- *s++ = '\n';
- break;
- case 'r':
- *s++ = '\r';
- break;
- case 't':
- *s++ = '\t';
- break;
- case '\\':
- *s++ = '\\';
- break;
- case '\r':
- /* \ <cr> <lf> -> line continuation */
- if (x[1] != '\n') {
- x++;
- continue;
- }
- case '\n':
- /* \ <lf> -> line continuation */
- state->line++;
- x++;
- /* eat any extra whitespace */
- while((*x == ' ') || (*x == '\t')) x++;
- continue;
- default:
- /* unknown escape -- just copy */
- *s++ = *x++;
- }
- continue;
- default:
- *s++ = *x++;
- }
- }
- return T_EOF;
- }
next_token函数的代码还是很多的，不过原理到很简单。就是逐一读取init.rc文件（还有import导入的初始化文件）的字符，并将由空格、“/t”和“/r”分隔的字符串挑出来，并通过state->text返回。如果返回了正常的token，next_token函数就返回T_TEXT。如果一行结束，就返回T_NEWLINE，如果init.rc文件的内容已读取完，就返回T_EOF。当返回T_NEWLINE时，开始语法分析（由于init初始化语言是基于行的，所以语言分析实际上就是分析init.rc文件的每一行，只是这些行已经被分解成一个个token了）。感兴趣的读者可以详细分析一下next_token函数的代码，尽管代码很多，但并不复杂。而且还很有意思。
现在回到parse_config函数，先看一下T_TEXT分支。该分支将获得的每一行的token都存储在args数组中。现在来看T_NEWLINE分支。该分支的代码涉及到一个state.parse_line函数指针，该函数指针指向的函数负责具体的分析工作。但我们发现，一看是该函数指针指向了一个空函数parse_line_no_op，实际上，一开始该函数指针什么都不做，只是为了使该函数一开始不至于为null，否则调用出错。
现在来回顾一下T_NEWLINE分支的完整代码。
- case T_NEWLINE:
- state.line++;
- if (nargs) {
- int kw = lookup_keyword(args[0]);
- if (kw_is(kw, SECTION)) {
- state.parse_line(&state, 0, 0);
- parse_new_section(&state, kw, nargs, args);
- } else {
- state.parse_line(&state, nargs, args);
- }
- nargs = 0;
- }
- break;
- int lookup_keyword(const char *s)
- {
- switch (*s++) {
- case 'c':
- if (!strcmp(s, "opy")) return K_copy;
- if (!strcmp(s, "apability")) return K_capability;
- if (!strcmp(s, "hdir")) return K_chdir;
- if (!strcmp(s, "hroot")) return K_chroot;
- if (!strcmp(s, "lass")) return K_class;
- if (!strcmp(s, "lass_start")) return K_class_start;
- if (!strcmp(s, "lass_stop")) return K_class_stop;
- if (!strcmp(s, "lass_reset")) return K_class_reset;
- if (!strcmp(s, "onsole")) return K_console;
- if (!strcmp(s, "hown")) return K_chown;
- if (!strcmp(s, "hmod")) return K_chmod;
- if (!strcmp(s, "ritical")) return K_critical;
- break;
- case 'd':
- if (!strcmp(s, "isabled")) return K_disabled;
- if (!strcmp(s, "omainname")) return K_domainname;
- break;
- … …
- case 'o':
- if (!strcmp(s, "n")) return K_on;
- if (!strcmp(s, "neshot")) return K_oneshot;
- if (!strcmp(s, "nrestart")) return K_onrestart;
- break;
- case 'r':
- if (!strcmp(s, "estart")) return K_restart;
- if (!strcmp(s, "estorecon")) return K_restorecon;
- if (!strcmp(s, "mdir")) return K_rmdir;
- if (!strcmp(s, "m")) return K_rm;
- break;
- case 's':
- if (!strcmp(s, "eclabel")) return K_seclabel;
- if (!strcmp(s, "ervice")) return K_service;
- if (!strcmp(s, "etcon")) return K_setcon;
- if (!strcmp(s, "etenforce")) return K_setenforce;
- if (!strcmp(s, "etenv")) return K_setenv;
- if (!strcmp(s, "etkey")) return K_setkey;
- if (!strcmp(s, "etprop")) return K_setprop;
- if (!strcmp(s, "etrlimit")) return K_setrlimit;
- if (!strcmp(s, "etsebool")) return K_setsebool;
- if (!strcmp(s, "ocket")) return K_socket;
- if (!strcmp(s, "tart")) return K_start;
- if (!strcmp(s, "top")) return K_stop;
- if (!strcmp(s, "ymlink")) return K_symlink;
- if (!strcmp(s, "ysclktz")) return K_sysclktz;
- break;
- case 't':
- if (!strcmp(s, "rigger")) return K_trigger;
- break;
- case 'u':
- if (!strcmp(s, "ser")) return K_user;
- break;
- case 'w':
- if (!strcmp(s, "rite")) return K_write;
- if (!strcmp(s, "ait")) return K_wait;
- break;
- }
- return K_UNKNOWN;
- }
lookup_keyword方法按26个字母顺序（关键字首字母）进行处理。
现在回到parse_config方法的T_NEWLIEN分支，接下来调用了kw_is宏具体判断当前行是否合法，该宏以及SECTION宏的定义如下。根据这些代码。明显是keyword_info数组中的某个元素的flags成员变量的值取最后一位。
- #define SECTION 0x01
- #define kw_is(kw, type) (keyword_info[kw].flags & (type))
现在问题又转到keyword_info数组了。该数组也在init_parser.c文件中定义，代码如下:
- #include "keywords.h"
- #define KEYWORD(symbol, flags, nargs, func) \
- [ K_##symbol ] = { #symbol, func, nargs + 1, flags, },
- struct {
- const char *name;
- int (*func)(int nargs, char **args);
- unsigned char nargs;
- unsigned char flags;
- } keyword_info[KEYWORD_COUNT] = {
- [ K_UNKNOWN ] = { "unknown", 0, 0, 0 },
- #include "keywords.h"
- };
从表面上看，keyword_info数组是一个struct数组，但本质上，是一个map。为每一个数组元素设置了一个key，例如，数组元素{ "unknown", 0, 0,0 }的key是K_UNKNOWN，而#include “keywords.h”大有玄机。上面的代码中引用了两次keywords.h文件，现在可以看一下keywords.h文件的代码。
- #ifndef KEYWORD
- int do_chroot(int nargs, char **args);
- … …
- int do_export(int nargs, char **args);
- int do_hostname(int nargs, char **args);
- int do_rmdir(int nargs, char **args);
- int do_loglevel(int nargs, char **args);
- int do_load_persist_props(int nargs, char **args);
- int do_wait(int nargs, char **args);
- #define __MAKE_KEYWORD_ENUM__
- /*
- "K_chdir", ENUM
- */
- #define KEYWORD(symbol, flags, nargs, func) K_##symbol,
- enum {
- K_UNKNOWN,
- #endif
- KEYWORD(capability, OPTION, 0, 0)
- KEYWORD(chdir, COMMAND, 1, do_chdir)
- KEYWORD(chroot, COMMAND, 1, do_chroot)
- KEYWORD(class, OPTION, 0, 0)
- KEYWORD(class_start, COMMAND, 1, do_class_start)
- KEYWORD(class_stop, COMMAND, 1, do_class_stop)
- KEYWORD(class_reset, COMMAND, 1, do_class_reset)
- KEYWORD(console, OPTION, 0, 0)
- … …
- KEYWORD(critical, OPTION, 0, 0)
- KEYWORD(load_persist_props, COMMAND, 0, do_load_persist_props)
- KEYWORD(ioprio, OPTION, 0, 0)
- #ifdef __MAKE_KEYWORD_ENUM__
- KEYWORD_COUNT,
- };
- #undef __MAKE_KEYWORD_ENUM__
- #undef KEYWORD
- #endif
从keywords.h文件的代码可以看出，如果未定义KEYWORD宏，则在keywords.h文件中定义一个KEYWORD宏，以及一个枚举类型，其中K_##symbol的##表示连接的意思。而这个KEYWORD宏只用了第一个参数（symbol）。例如，KEYWORD(chdir, COMMAND, 1, do_chdir)就会生成K_chdir。
而在keyword_info结构体数组中再次导入keywords.h文件，这是KEYWORD宏已经在init_parser.c文件中重新定义，所以第一次导入keywords.h文件使用的是如下的宏。
- #define KEYWORD(symbol, flags, nargs, func) \
- [ K_##symbol ] = { #symbol, func, nargs + 1, flags, },
- int do_chroot(int nargs, char **args);
- … …
- enum
- {
- K_UNKNOWN,
- K_ capability,
- K_ chdir,
- … …
- }
- #define KEYWORD(symbol, flags, nargs, func) \
- [ K_##symbol ] = { #symbol, func, nargs + 1, flags, },
- struct {
- const char *name;
- int (*func)(int nargs, char **args);
- unsigned char nargs;
- unsigned char flags;
- } keyword_info[KEYWORD_COUNT] = {
- [ K_UNKNOWN ] = { "unknown", 0, 0, 0 },
- [K_ capability] = {" capability ", 0, 1, OPTION },
- [K_ chdir] = {"chdir", do_chdir ,2, COMMAND},
- … …
- #include "keywords.h"
- };
在keywords.h前面定义的函数指针都是处理init.rc文件中service、action和command的。现在就剩下一个问题了，在哪里为这些函数指针赋值呢，也就是说，具体处理每个部分的函数在哪里呢。现在回到前面的语法分析部分。如果当前行合法，则会执行parse_new_section函数（在init_parser.c文件中实现），该函数将为section和action设置处理这两部分的函数。parse_new_section函数的代码如下：
- void parse_new_section(struct parse_state *state, int kw,
- int nargs, char **args)
- {
- printf("[ %s %s ]\n", args[0],
- nargs > 1 ? args[1] : "");
- switch(kw) {
- case K_service: // 处理service
- state->context = parse_service(state, nargs, args);
- if (state->context) {
- state->parse_line = parse_line_service;
- return;
- }
- break;
- case K_on: // 处理action
- state->context = parse_action(state, nargs, args);
- if (state->context) {
- state->parse_line = parse_line_action;
- return;
- }
- break;
- case K_import: // 单独处理import导入的初始化文件。
- parse_import(state, nargs, args);
- break;
- }
- state->parse_line = parse_line_no_op;
- }
现在看一下处理service的函数（parse_line_service）。
- static void parse_line_service(struct parse_state *state, int nargs, char **args)
- {
- struct service *svc = state->context;
- struct command *cmd;
- int i, kw, kw_nargs;
- if (nargs == 0) {
- return;
- }
- svc->ioprio_class = IoSchedClass_NONE;
- kw = lookup_keyword(args[0]);
- // 下面处理每一个option
- switch (kw) {
- case K_capability:
- break;
- … …
- case K_group:
- if (nargs < 2) {
- parse_error(state, "group option requires a group id\n");
- } else if (nargs > NR_SVC_SUPP_GIDS + 2) {
- parse_error(state, "group option accepts at most %d supp. groups\n",
- NR_SVC_SUPP_GIDS);
- } else {
- int n;
- svc->gid = decode_uid(args[1]);
- for (n = 2; n < nargs; n++) {
- svc->supp_gids[n-2] = decode_uid(args[n]);
- }
- svc->nr_supp_gids = n - 2;
- }
- break;
- case K_keycodes:
- if (nargs < 2) {
- parse_error(state, "keycodes option requires atleast one keycode\n");
- } else {
- svc->keycodes = malloc((nargs - 1) * sizeof(svc->keycodes[0]));
- if (!svc->keycodes) {
- parse_error(state, "could not allocate keycodes\n");
- } else {
- svc->nkeycodes = nargs - 1;
- for (i = 1; i < nargs; i++) {
- svc->keycodes[i - 1] = atoi(args[i]);
- }
- }
- }
- break;
- … …
- }
- ……
- }
Action的处理方式与service类似，读者可以自行查看相应的函数代码。现在一切都清楚了。处理service的函数是parse_line_service，处理action的函数是parse_line_action。而前面的state.parse_line根据当前是service还是action，指向这两个处理函数中的一个，并执行相应的函数处理actioncommand和serviceoption。
综合上述，实际上分析init.rc文件的过程就是通过一系列地处理，最终转换为通过parse_line_service或parse_line_action函数分析Init.rc文件中每一行的行为。