init.rc文件解析过程
Android init 语法解析 http://www.cnblogs.com/shed/p/3718548.html
Android init.rc 文件解析 http://www.cnblogs.com/shed/p/3722947.html
我们已经知道init.rc的结构，应该可以想到解析init.rc的过程就是识别一个个section的过程，将各个section的信息保存下来，然后在init.c的main()中去执行一个个命令。
android采用双向链表(关于双向链表详解见本文第三部分)来存储section的信息，解析完成之后，会得到三个双向链表action_list、service_list、import_list来分别存储三种section的信息上。
1. init.c中调用init_parse_config_file(“/init.rc”)， 代码如下：
int init_parse_config_file(const char *fn)
{
char *data;
data = read_file(fn, 0); //read_file()调用openlseek ead 将init.rc读出来
if (!data) return -1;
parse_config(fn, data); //调用parse_config开始解析
DUMP();
return 0;
}
2. parse_config()代码如下：
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;
for (;;) {
switch (next_token(&state)) { //next_token()根据从state.ptr开始遍历
case T_EOF: //遍历到文件结尾，然后goto解析import的.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)) { //查看关键字是否为Section，只有Service 和 on 满足
state.parse_line(&state, 0, 0);
parse_new_section(&state, kw, nargs, args); //解析on 或service
} else { //如果这不是一个Section的第一行,那就是service 或on 下面的内容
state.parse_line(&state, nargs, args);
}
nargs = 0;
}
break;
case T_TEXT: //遇到普通字符
if (nargs < INIT_PARSER_MAXARGS) {
args[nargs++] = state.text;
}
break;
}/*switch*/
}/*for(;;)*/
parser_done:
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' ", import->filename, fn);
}
}/*parse_config*/
next_token() 解析完init.rc中一行之后，会返回T_NEWLINE，这时调用lookup_keyword函数来找出这一行的关键字, lookup_keyword返回的是一个整型值，对应keyword_info[]数组的下标，keyword_info[]存放的是keyword_info结构体类型的数据，
struct {
const char *name; //关键字的名称
int (*func)(int nargs, char **args); //对应的处理函数
unsigned char nargs; //参数个数
unsigned char flags; //flag标识关键字的类型,包括COMMAND、OPTION、SECTION
} keyword_info
因此keyword_info[]中存放的是所有关键字的信息，每一项对应一个关键字。
keyword_info 结构体定义在： system/core/init/init_parser.c
keyword_info[] 定义在： system/core/init/keywords.h
根据每一项的flags就可以判断出关键字的类型，如新的一行是SECTION，就调用parse_new_section()来解析这一行, 如新的一行不是一个SECTION的第一行，那么调用state.parseline()来解析(state.parseline所对应的函数会根据section类型的不同而不同)，在parse_new_section()中进行动态设置。
三种类型的section: service、on、import,
service 对应的state.parseline为 parse_line_service,
on 对应的state.parseline为 parse_line_action,
import section中只有一行所以没有对应的state.parseline。
3、parse_new_section 代码如下:
void parse_new_section(struct parse_state *state, int kw, int nargs, char **args)
{
printf("[ %s %s ] ", args[0], nargs > 1 ? args[1] : "");
switch(kw) {
case K_service: \解析service类型的section
state->context = parse_service(state, nargs, args);
if (state->context) {
state->parse_line = parse_line_service;
return;
}
break;
case K_on: \解析on类型的section
state->context = parse_action(state, nargs, args);
if (state->context) {
state->parse_line = parse_line_action;
return;
}
break;
case K_import: \解析import类型的section
parse_import(state, nargs, args);
break;
}
state->parse_line = parse_line_no_op;
}
4、parse_service()和parse_line_service()
parse_service()代码如下：
static void *parse_service(struct parse_state *state, int nargs, char **args)
{
struct service *svc;
if (nargs < 3) {
parse_error(state, "services must have a name and a program ");
return 0;
}
if (!valid_name(args[1])) {
parse_error(state, "invalid service name '%s' ", args[1]);
return 0;
}
svc = service_find_by_name(args[1]); //在链表中查找当前行对应的service
if (svc) {
parse_error(state, "ignored duplicate definition of service '%s' ", args[1]);
return 0;
}
//如果当前行对应的service还没有加入service_list链表，则新建一个
nargs -= 2;
svc = calloc(1, sizeof(*svc) + sizeof(char*) * nargs);
if (!svc) {
parse_error(state, "out of memory ");
return 0;
}
svc->name = args[1]; // service 的名字
svc->classname = "default"; //svc 的类名默认为default
memcpy(svc->args, args + 2, sizeof(char*) * nargs); //首个参数放的是可执行文件
svc->args[nargs] = 0;
svc->nargs = nargs; //参数的个数
svc->onrestart.name = "onrestart";
list_init(&svc->onrestart.commands);
list_add_tail(&service_list, &svc->slist); //将这个service加入到service_list
//注意此时svc对象基本上是一个空壳，因为相关的options还没有解析
return svc;
}
parse_line_service()解析service对应的options行，主要是填充parse_service()中创建的service对象。
5、parse_action()和parse_line_action()
parse_action()函数主要是根据当前行的信息创建一个action结构体类型的对象，加入到action_list双向链表中, 代码比较简单，有兴趣可自行研究。
parse_line_action()解析对应的命令行, 代码如下:
static void parse_line_action(struct parse_state* state, int nargs, char **args)
{
struct command *cmd;
struct action *act = state->context;
int (*func)(int nargs, char **args);
int kw, n;
if (nargs == 0) {
return;
}
kw = lookup_keyword(args[0]);
if (!kw_is(kw, COMMAND)) {
parse_error(state, "invalid command '%s' ", args[0]);
return;
}
n = kw_nargs(kw);
if (nargs < n) {
parse_error(state, "%s requires %d %s ", args[0], n - 1, n > 2 ? "arguments" : "argument");
return;
}
cmd = malloc(sizeof(*cmd) + sizeof(char*) * nargs); //生成一个command类型的对象
cmd->func = kw_func(kw);
cmd->nargs = nargs;
memcpy(cmd->args, args, sizeof(char*) * nargs);
list_add_tail(&act->commands, &cmd->clist); //将这个command对象加入actions->commands
}
一个on类型的section对应一个action， action类型定义如下：
struct action {
/* node in list of all actions */
struct listnode alist;
/* node in the queue of pending actions */
struct listnode qlist;
/* node in list of actions for a trigger */
struct listnode tlist;
unsigned hash;
const char *name;
struct listnode commands; //command的双向链表
struct command *current;
};
因此，每个on类型section的第二行开始每一行都解析了一个command, 所有command组成一个双向链表指向该action的commands字段中。
三、相关结构体
1、listnode
listnode 结构体用于建立双向链表，这种结构广泛用于kernel代码中, android源代码中定义了listnode结构体以及相关操作双向链表的方法，与kernel中的定义类似。
listnode 定义在：system/core/include/cutils/list.h
system/core/libcutils/list.c
这个实现的核心思想是：在用户自定义的结构体xx中定义一个listnode类型的成员,
这个listnode类型成员的作用就是能将xx类型的变量组成一个双向链表。下面我们来看一下是listnode是怎么做到的。
//listnode 类型里面只有两个指针prev,next
struct listnode
{
struct listnode *next;
struct listnode *prev;
};
//将链表中的一个node转换成自定义结构体中的一个对象
#define node_to_item(node, container, member)
(container *) (((char*) (node)) - offsetof(container, member))
//初始化一个链表
void list_init(struct listnode *node)
{
node->next = node;
node->prev = node;
}
//将一个节点到链表
void list_add_tail(struct listnode *head, struct listnode *item)
{
item->next = head;
item->prev = head->prev;
head->prev->next = item;
head->prev = item;
}
//删除一个节点
void list_remove(struct listnode *item)
{
item->next->prev = item->prev;
item->prev->next = item->next;
}
理解node_to_item宏是理解listnode用法的关键，这个宏的作用是将一个listnode指针转换成了一个指定类型（自定义）的指针，这个宏先使用offsetof函数获取到指定结构体中指定成员变量的地址偏移量，然后通过指针运算获得listnode指针变量所在结构体变量的指针。
这种实现与我们课堂上所学的链表实现方法不太一样，教科书上的实现是在listnode中存储了自定义的数据，而这个实现是在自定义的数据当中存储listnode指针。
2、action结构体
前面已经讲过on类型的section解析之后会生成一个双向链表action_list, 这个action_list每个node表示就是action结构体的对象，也就是说一个on类型的section都会生成一个action结构体的对象。
action,command,service defined by: system/core/init/init.h
action结构体定义如下:
struct action {
/* node in list of all actions */
struct listnode alist;
/* node in the queue of pending actions */
struct listnode qlist;
/* node in list of actions for a trigger */
struct listnode tlist;
unsigned hash;
const char *name;
struct listnode commands; //节点为command结构体的双向链表
struct command *current;
};
action结构体除了用在on类型的section, 也用在service类型的section，下面介绍service结构体时会说明。
3、command结构体
Command结构体定义如下:
struct command
{
/* list of commands in an action */
struct listnode clist;
int (*func)(int nargs, char **args);
int nargs;
char *args[1];
};
command结构体比较简单, 用于标识一个命令，包含双向链表指针、对应的执行函数、参数个数以及命令关键字。
4、service结构体
struct service {
/* list of all services */
struct listnode slist; //将结构体链接成service_list用
const char *name;
const char *classname;
unsigned flags;
pid_t pid;
time_t time_started; /* time of last start */
time_t time_crashed; /* first crash within inspection window */
int nr_crashed; /* number of times crashed within window */
uid_t uid;
gid_t gid;
gid_t supp_gids[NR_SVC_SUPP_GIDS];
size_t nr_supp_gids;
#ifdef HAVE_SELINUX
char *seclabel;
#endif
struct socketinfo *sockets;
struct svcenvinfo *envvars;
struct action onrestart; /* Actions to execute on restart. */
/* keycodes for triggering this service via /dev/keychord */
int *keycodes;
int nkeycodes;
int keychord_id;
int ioprio_class;
int ioprio_pri;
int nargs;
/* "MUST BE AT THE END OF THE STRUCT" */
char *args[1];
};
service结构体存储了service的相关信息, 包括进程号、启动时间、名字等, 字段onrestart
就用到了action结构体， onrestart这个option后面通常跟着一个命令，所以也用action结构体来表示。
此处贴上init.c: 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;
bool is_special = false;
#ifdef MANUALENABLE
/* enable bootchart if asked by user */
if (getenv("bootchart"))
enablechart = 1;
#endif
/* If we are called as 'modprobe' command, we run as a
* standalone executable and reuse ueventd's logic to do the job.
*/
if (!strcmp(basename(argv[0]), "ueventd")
|| !strcmp(basename(argv[0]), "modprobe"))
return ueventd_main(argc, argv);
if (!strcmp(basename(argv[0]), "watchdogd"))
return watchdogd_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.
*/
//为rootfs建立必要的文件夹，并挂载适当的分区
mkdir("/dev", 0755);
mkdir("/proc", 0755);
mkdir("/sys", 0755);
mount("tmpfs", "/dev", "tmpfs", MS_NOSUID, "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);
/* indicate that booting is in progress to background fw loaders, etc */
close(open("/dev/.booting", O_WRONLY | O_CREAT, 0000));
/* 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.
*/
//创建/dev/null节点,需要在后面的程序中看到打印信息的话， 需要屏蔽这个函数
open_devnull_stdio();
klog_init(); // log 系统初始化
INFO("system/core/init.c--main()
");
property_init();
INFO("reading property config file
");
init_parse_config_file("/props.rc");
get_hardware_name(hardware, &revision);
process_kernel_cmdline();
union selinux_callback cb;
cb.func_log = klog_write;
selinux_set_callback(SELINUX_CB_LOG, cb);
cb.func_audit = audit_callback;
selinux_set_callback(SELINUX_CB_AUDIT, cb);
selinux_initialize();
/* These directories were necessarily created before initial policy load
* and therefore need their security context restored to the proper value.
* This must happen before /dev is populated by ueventd.
*/
restorecon("/dev");
restorecon("/dev/socket");
restorecon("/dev/__properties__");
restorecon_recursive("/sys");
is_special = is_special_bootmode(bootmode);
INFO("property init
");
if (!is_special)
property_load_boot_defaults();
/* Clear the init.props action list. All the properties
* derivation is now done. No need to overload further action_list
* processing
*/
clear_action_list();
INFO("reading config file
");
//解析/init.rc，将所有服务和操作信息加入链表
init_parse_config_file("/init.rc");
//触发init.rc 中 “early-init” 的命令。
action_for_each_trigger("early-init", action_add_queue_tail);
//queue_builtin_action来向init进程中的一个待执行action队列增加了一个名称等于“console_init”的action。这个action对应的执行函数为console_init_action，它就是用来显示第二个开机画面的
queue_builtin_action(wait_for_coldboot_done_action, "wait_for_coldboot_done");
queue_builtin_action(mix_hwrng_into_linux_rng_action, "mix_hwrng_into_linux_rng");
queue_builtin_action(keychord_init_action, "keychord_init");
queue_builtin_action(console_init_action, "console_init");
INFO("action_for_each_trigger--init
");
/* execute all the boot actions to get us started */
action_for_each_trigger("init", action_add_queue_tail);
INFO("action_for_each_trigger--early-fs--fs--post-fs--post-fs-data
");
/* skip mounting filesystems in special mode */
if (!is_special) {
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);
action_for_each_trigger("post-fs-data", action_add_queue_tail);
}
/* Repeat mix_hwrng_into_linux_rng in case /dev/hw_random or /dev/random
* wasn't ready immediately after wait_for_coldboot_done
*/
queue_builtin_action(mix_hwrng_into_linux_rng_action, "mix_hwrng_into_linux_rng");
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");
INFO("action_for_each_trigger--early-boot--boot
");
if (is_special) {
action_for_each_trigger(bootmode, action_add_queue_tail);
} else {
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_property_triggers");
#if BOOTCHART
#ifdef MANUALENABLE
if (enablechart)
#endif
queue_builtin_action(bootchart_init_action, "bootchart_init");
#endif
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
#ifdef MANUALENABLE
if (enablechart)
#endif
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;
}
回到init进程的入口函数main中，最后init进程会进入到一个无限循环中去。在这个无限循环中，init进程会做以下五个事情：
A. 调用函数execute_one_command来检查action_queue列表是否为空。如果不为空的话，那么init进程就会将保存在列表头中的action移除，并且执行这个被移除的action。由于前面我们将一个名称为“console_init”的action添加到了action_queue列表中，因此，在这个无限循环中，这个action就会被执行，即函数console_init_action会被调用。
B. 调用函数restart_processes来检查系统中是否有进程需要重启。在启动脚本/init.rc中，我们可以指定一个进程在退出之后会自动重新启动。在这种情况下，函数restart_processes就会检查是否存在需要重新启动的进程，如果存在的话，那么就会将它重新启动起来。
C. 处理系统属性变化事件。当我们调用函数property_set来改变一个系统属性值时，系统就会通过一个socket（通过调用函数get_property_set_fd可以获得它的文件描述符）来向init进程发送一个属性值改变事件通知。init进程接收到这个属性值改变事件之后，就会调用函数handle_property_set_fd来进行相应的处理。后面在分析第三个开机画面的显示过程时，我们就会看到，SurfaceFlinger服务就是通过修改“ctl.start”和“ctl.stop”属性值来启动和停止第三个开机画面的。
D. 处理一种称为“chorded keyboard”的键盘输入事件。这种类型为chorded keyboard”的键盘设备通过不同的铵键组合来描述不同的命令或者操作，它对应的设备文件为/dev/keychord。我们可以通过调用函数get_keychord_fd来获得这个设备的文件描述符，以便可以监控它的输入事件，并且调用函数handle_keychord来对这些输入事件进行处理。
E. 回收僵尸进程。我们知道，在Linux内核中，如果父进程不等待子进程结束就退出，那么当子进程结束的时候，就会变成一个僵尸进程，从而占用系统的资源。为了回收这些僵尸进程，init进程会安装一个SIGCHLD信号接收器。当那些父进程已经退出了的子进程退出的时候，内核就会发出一个SIGCHLD信号给init进程。init进程可以通过一个socket（通过调用函数get_signal_fd可以获得它的文件描述符）来将接收到的SIGCHLD信号读取回来，并且调用函数handle_signal来对接收到的SIGCHLD信号进行处理，即回收那些已经变成了僵尸的子进程。
注意，由于后面三个事件都是可以通过文件描述符来描述的，因此，init进程的入口函数main使用poll机制来同时轮询它们，以便可以提高效率。
other---
queue_builtin_action(int (*func)(int nargs,char **args), char *name)是以name形成action，挂在action_list上；以func和name组成command，挂在action的commands上。然后加入到action_queue的队尾。
进入无限循环中for(;;)
9.1 execute_one_command():[system/core/init/init.c]
1) 从action_queue取下structaction *act赋给cur_action；
2) 从cur_action获得struct command *赋给cur_command；
3) 执行cur_command->func(cur_command->nargs, cur_command->args)
注1：以上是第一次执行时，如果action中还有command，就不需要1，而2中就是直接再在action上取下一条command即可。
注2：这里才是真正地命令的执行，前面的action_for_each_trigger()和queue_builtin_action()只是加入到action_queue队列中，而这里是从队列中顺序取出，并执行。
所以，加入队列action_queue的顺序也就决定了执行的顺序。Init???.rc中action所在的section决定了它们执行的先后次序：early-init -> init -> early-fs -> fs -> post-fs ->early-boot -> boot。
9.2 restart_processes():system/core/init/init.c
对有SVC_RESTARTING标志的service，执行restart_service_if_needed()
9.3 用poll等待几个事件：property事件/子进程结束的signal事件/keychord
9.4 处理等到的事件
对property_set事件，调用handle_property_set_fd()处理；
对keychord事件，调用handle_keychord()处理；
对signal事件，调用handle_signal()处理；
Ref:
http://www.docin.com/p-623861334.html
http://blog.csdn.net/persuit/article/details/7693479