标准系统的进程拉起方式简介 原创 精华
【本文正在参与优质创作者激励】标准系统启动到进入用户态拉起init进程后,由init进程拉起一组系统服务进程,再由这组系统服务进程拉起与之相关联的子进程,或者应用进程。
下面我们简单看一下标准系统的几种进程拉起方式。
1.init直接拉起系统服务进程
init进程启动到InitReadCfg()时,去读取和分析/system/etc/init.cfg和/system/etc/init/*.cfg。
其中init.cfg与小型系统的有较大差别,其主要工作是配置各个启动阶段所需要的环境,比如创建文件节点、修改相关节点的权限等,而不是直接去start全部的系统进程。各个系统进程的start和相关配置,基本上是由/system/etc/init/目录下的各进程自己的cfg文件进行配置的。
init进程将各进程的配置读取和分析后,在启动到具体的阶段时,会去触发和按顺序执行各个系统进程的start命令:
DoStart -> StartServiceByName -> ServiceStart -> fork()+execve(),直接就去运行进程自己的cfg文件中"path" 指定的可执行程序,切换到进程的上下文环境去运行了,这就完成了init的第一代子进程的启动,典型的例子可以看appspawn进程的启动。
2.借sa_main启动的系统进程
有部分系统进程,自己的代码并不直接编译生成可执行程序,而是编译生成一个动态链接库,如softbus_server进程,直接编译生成libsoftbus_server.z.so,该进程的cfg中是这样配置的:
它的"path"字段配置的是去运行"/system/bin/sa_main"可执行程序,再通过sa_main里的DoStartSAProcess()根据/system/profile/softbus_server.xml的描述,去加载libsoftbus_server.z.so,以此来切换到softbus_server进程的上下文中运行。
标准系统中借sa_main可执行程序来启动的进程非常多,在/system/etc/init/目录下的cfg中有详细描述。
3.借其它可执行程序启动的系统进程
这种类似于第2种,但借用的可执行程序,不像sa_main那样具有系统级别的通用性,而是只具有子系统级别的局部通用性。典型的例子是标准系统部署在用户态的驱动框架的各进程。
先按第1种方式拉起hdf_devmgr进程,待启动到具体阶段时,hdf_devmgr进程会通过fork()+execve()去运行hdf_devhost可执行程序。这个hdf_devhost就是只适用于驱动框架的通用进程入口,它会根据execve()送进来的参数去加载各个具体host的动态库,如libsample_driver.z.so,由此进入sample_host进程的的上下文环境中去运行。这样就完成了一组host进程的拉起,这组host进程都是hdf_devmgr进程的子进程。
赞,大佬出书一定支持!
不错!
把 “sa_main启动”的原理分析下就最好,现在相当于个黑盒子,
这个应该是 鸿蒙搞出来的概念,或者还是从 三星 tizen 学过来的。
https://gitee.com/openharmony/distributedschedule_safwk
在系统服务管理子系统中safwk组件定义OpenHarmony中SystemAbility的实现方法,并提供启动、注册等接口实现。
SystemAbility实现一般采用XXX.cfg + profile.xml + libXXX.z.so的方式由init进程执行对应的XXX.cfg文件拉起相关SystemAbility进程。
C++实现SystemAbility
说的很清楚啦,已经找到
谢谢分享