鸿蒙liteos-a如何启动第一个用户进程init_lite

小嵌

鸿蒙liteos-a如何启动第一个用户进程init_lite, 1. 鸿蒙OS编译知识

OpenHARMony源码编译系统使用了google开发的gn工具以及ninjia。这二者结合起来比传统的makefile编译系要高效，尤其适合大系统的并行编译。对开发者而言，如果要参与OpenHarmony的开发，需要对gn的语法有些了解。本文仅做一些最基本的介绍：

1.使用gn工具的话，开发者将编译规则写在名为BUILD.gn文件中。和Makefile一样，gn文件有自己的语法规则，属于领域语言（Domain SpecIFic Language，DSL）。gn语法不难，但编译规则本身有很多内容，所以一下子要掌握全部内容也不容易。

2.gn支持自定义模板函数，可放在名为.gni的文件中。OpenHarmony中最常见到的gn模板文件为./build/lite/config/component/lite_component.gni。.gn文件中通过import可导入gni模板文件。OpenHarmony定义了lite_component、lite_library等模板函数。

3.gn中，可执行文件的编译函数入口为exectuable（“文件名”），共享库的编译规则函数为shared_library（“文件名”）。所以，如果要搜索某个文件对应的编译规则，可以先搜索所有的BUILD.gn文件，然后grep executable。以下是grep所有的executable的结果截图。



（以上原理引自中科创达OpenHarmony研究组 鸿蒙OS开源代码精要解读之——init）



2. 从编译过程看鸿蒙OS代码结构

Hi3518EV300的编译命令如下：

python build.py ipcamera_hi3518ev300 -b debug

这条编译命令是怎么执行的呢？



编译的主文件是Build\lite\BUILD.gn文件，内容截取如下：



先编译kernel，依赖库；最后编译rootfs, rootfs的编译过程\build\lite\gen_rootfs.py打开看是先编译useRFs，再编译rootfs。

使用到的配置文件：



打开ipcamera_hi3518ev300.json，其中：

1.配置kernel为liteos_a；

2.指定编译器为clang；

3.列出了所有OS子系统和源码位置，包括了kernel、startup子系统。Startup中的init_lite是kernel调用的第一个用户态进程；



3. 第一个用户态进程init_lite

Init_lite的位置：



官方手册中对init的介绍 （init启动引导指的就是init_lite）

启动恢复负责在内核启动之后，应用启动之前的操作系统中间层的启动。涉及以下模块：

·         init启动引导

支持使用LiteOS-A内核的平台，当前包括：Hi3516DV300平台和Hi3518EV300平台。

负责处理从内核加载第一个用户态进程开始，到第一个应用程序启动之间的系统服务进程启动过程。启动恢复子系统除负责加载各系统关键进程之外，还需在启动的同时设置其对应权限，并在子进程启动后对指定进程实行保活（若进程意外退出要重新启动），对于特殊进程意外退出时，启动恢复子系统还要执行系统复位操作。

·         appspawn应用孵化

支持使用LiteOS-A内核的平台，当前包括：Hi3516DV300平台和Hi3518EV300平台。

负责接受应用程序框架的命令孵化应用进程，设置其对应权限，并调用应用程序框架的入口。

·         bootstrap启动服务模块

支持使用LiteOS-M内核的平台，当前包括：Hi3861平台。

提供了各服务和功能的启动入口标识。在SAMGR启动时，会调用boostrap标识的入口函数，并启动系统服务。

·         系统属性

支持使用LiteOS-M内核和LiteOS-A内核的平台，包括：Hi3861平台，Hi3516DV300平台，Hi3518EV300平台。

负责提供获取与设置操作系统相关的系统属性。

系统属性包括：默认系统属性、OEM厂商系统属性和自定义系统属性。OEM厂商部分仅提供默认值，具体值需OEM产品方按需进行调整，详见“使用”部分。

base

├──startup 启动恢复子系统根目录

├──── frameworks

│ └── syspara_lite

│ ├── LICENSE 开源LICENSE文件

│ ├── parameter 系统属性模块源文件目录

│ │ ├── BUILD.gn

│ │ └── src

│ │ ├── BUILD.gn

│ │ ├── param_impl_hal 系统属性模块基于LiteOS-M核实现

│ │ └── param_impl_posix 系统属性模块基于LiteOS-A核实现

│ └── token

│ ├── BUILD.gn

│ └── src

│ ├── token_impl_hal

│ └── token_impl_posix

├──── hals

│ └── syspara_lite 系统属性模块硬件抽象层头文件目录

├──── interfaces

│ └── kits

│ └── syspara_lite 系统属性模块对外接口目录

└──── services

├── appspawn_lite 应用孵化模块

│ ├── BUILD.gn 应用孵化模块编译配置

│ ├── include 应用孵化模块头文件目录

│ ├── LICENSE 开源LICENSE文件

│ ├── moduletest 应用孵化模块自测试代码目录

│ └── src 应用孵化木块源文件目录

├── bootstrap_lite 启动服务模块

│ ├── BUILD.gn 启动服务模块编译配置

│ ├── LICENSE 开源LICENSE文件

│ └── source 启动服务模块源文件目录

└── init_lite 启动引导模块

├── BUILD.gn 启动引导模块编译配置

├── include 启动引导模块头文件目录

├── LICENSE 开源LICENSE文件

├── moduletest 启动引导模块自测试代码目录

└── src 启动引导模块源文件目录

vendor

└──huawei

└──camera

└──init_configs 启动引导模块配置文件目录（json格式，部署于/etc/目录下）

Init_lite使用了配置文件init_configs；



Init_lite 的main.c会读取和执行上面的配置文件命令行，其函数为InitReadCfg；



Init_lite在编译后，生成”/bin/init”;

bin目录在\build\lite\BUILD.gn中配置；



init名称在base\startup\services\init_lite\BUILD.gn中指定；



4. Init_lite是如何被kernel调用的?

liteos-a的启动顺序是：

1）reset_vector_up.s

2）\kernel\liteos_a\platform\main.c

3）OsMain

4）OsSystemInit

5）OsSystemInitTaskCreate

6）SystemInit



Hi3518 kernel启动过程中会调用SystemInit：



SystemInit函数最后会调用OsUserInitProcess函数，启动init进程；



OsUserInitProcess函数在\kernel\liteos_a\kernel\base\core\los_process.c中定义：



OsUserInitProcess中定义了第一个用户态进程的地址是__user_init_entry;

__user_init_entry通过宏定义LITE_USER_SEC_ENTRY进行定义，其所在文件是\kernel\liteos_a\kernel\user\src\los_user_init.c；

这就是Kernel调用init_lite的入口：