AndroidInitProcess分析心得(3)

一路跑下来, 我们可以发现终于看到我们想看的command元素了, 原来在每一个act元素中还有一串由act元素所带的comand建立的cmdlinked list, 每一个comand元素会有一个func的functionpointer. 这个function pointer就是由kw_func macro所指定的.

//system\core\init\init_parser.c
#define kw_func(kw) (keyword_info[kw].func)

由这个macro可以知道, 其所指定的function就看kw_func macro所带的参数kw经由keyword_infomapping table去指定的.

        回到执行流程的execute_one_command函数继续分析, 由上面的一些细节可以对于cur_command所带的function跟keyword_info mapping table中所记录的function有关.Example:

//system\core\rootdir\init.rc
write /proc/sys/kernel/panic_on_oops 1

会经由keyword_info mapping table中的

KEYWORD(write,       COMMAND, 2, do_write)

呼叫到

\\system\core\init\builtins.c
int do_write(int nargs, char **args)
{
    const char *path = args[1];
    const char *value = args[2];
    char prop_val[PROP_VALUE_MAX];
    int ret;

    ret = expand_props(prop_val, value, sizeof(prop_val));
    if (ret) {
        ERROR("cannot expand '%s' while writing to '%s'\n", value, path);
        return -EINVAL;
    }
    return write_file(path, prop_val);
}

创建filesystem path node

        Init process是android的一个启动的process,在initprocess一启动就会开始建构一些file system.

//system\core\init\init.c
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);

首先先建构出三个目录, dev, proc, sys, 期三个目录所放的档案个不同.

/dev	在Linux下, 任何的周边装置都是以档案的形态存在这目录下. 要控制周边装置只要针对这目录下的档案路径作档案读写就行了.
/proc	本身是一个virtual file system, 里面放置的档案数据都会存在内存当中, 也就是说只有装置在执行时, 这目录下才会有档案出现..
/sys	本身是一个virtual file system, 跟/proc放置的档案不一样, 放的都是跟核心有关的数据或是核心侦测到的硬件装置信息..

之后会发现就在这三个主要的目录下挂载其他目录,和建构子目录.

 

监控系统属性变化跟事件

        Init process所监控的对象有property, signal, keychord. Init process一启动时便会针对这三个对像作initialize的动作.

// system\core\init\init.c
queue_builtin_action(keychord_init_action, "keychord_init");
queue_builtin_action(property_service_init_action, "property_service_init");
queue_builtin_action(signal_init_action, "signal_init");

queue_builtin_action函数只是将第一个函数包装成一个command, 然后在利用command组成一个act的数据元素, 之后在将这个act新增到action_list中, 之后再经由action_add_queue_tail将此新的act数据元素送进actionqueue中. 其command所带的函数会在前面所讨论的execute_one_command函数呼叫到.

        由于三个对像初始化的型为大同小异, 这里就举property来说明initial其间做哪些行为.

// system\core\init\init.c
static int property_service_init_action(int nargs, char **args)
{
    /* read any property files on system or data and
     * fire up the property service.  This must happen
     * after the ro.foo properties are set above so
     * that /data/local.prop cannot interfere with them.
     */
    start_property_service();
    return 0;
}

//system\core\init\property_service.c
void start_property_service(void)
{
    int fd;

    load_properties_from_file(PROP_PATH_SYSTEM_BUILD);
    load_properties_from_file(PROP_PATH_SYSTEM_DEFAULT);
    load_override_properties();
    /* Read persistent properties after all default values have been loaded. */
    load_persistent_properties();

    fd = create_socket(PROP_SERVICE_NAME, SOCK_STREAM, 0666, 0, 0);
    if(fd < 0) return;
    fcntl(fd, F_SETFD, FD_CLOEXEC);
    fcntl(fd, F_SETFL, O_NONBLOCK);

    listen(fd, 8);
    property_set_fd = fd;
}

一开始就会下载property配置文件, 这些档案存放的路径定义在_system_properties.h

// bionic\libc\include\sys\_system_properties.h
#define PROP_PATH_RAMDISK_DEFAULT  "/default.prop"
#define PROP_PATH_SYSTEM_BUILD     "/system/build.prop"
#define PROP_PATH_SYSTEM_DEFAULT   "/system/default.prop"
#define PROP_PATH_LOCAL_OVERRIDE   "/data/local.prop"

所有的android系统所吃的配置文件一开机就会从这些档案去读取. 至于propertyconfig file如何去编辑, 这不在这里的范围. 所以就不在这分析.下载完所有的property的设定值之后就开启socket去等待变化. 并把filedescriptor传给global 变数property_set_fd.

        一旦初始化之后, 就开始进入监控流程.

//system\core\init\init.c
int main(int argc, char **argv)
{
    //...
    for(;;) {
       // 执行action list 中的act的command.
       // 检查是否有service需要重新启动
       (1)
       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;
        }

        //....
       (2)
       nr = poll(ufds, fd_count, timeout);
        if (nr <= 0)
            continue;
       (3)
       for (i = 0; i < fd_count; i++) {
            if (ufds[i].revents == POLLIN) {
               if (ufds[i].fd == get_property_set_fd())
                    handle_property_set_fd();
               //....
            }
       }

    }
    return 0;
}

(1) 注册pollfd 结构, 其中get_property_set_fd 函数所取得的值就是之前在initial时期所开启socket的 filedescriptor.

(2) 开始进入polling监控变化. 一有变化才会继续第三步, 否则跳过接着下一次polling监控.

(3) 一有变化就开始比对所注册的filedescriptor, 之前有提到目前android(4.2)监控的对象有三个. 最后进入handlefunction.