OpenHarmony release3.1版本启动子系统功能分析 原创 精华

发布于 2022-4-16 10:58
浏览
5收藏

作者:润和软件 孙凡
1.技术背景
OpenHarmony release3.1版本在2.0的基础之上不仅增加了功能,而且各模块组件的能力也有所增强,本文就3.1版本的init启动子系统模块,在启动引导系统服务方面进行分析。本文档是基于码云上release3.1分支代码进行分析。
启动子系统负责整个系统各个进程运行时环境的构建及进程引导,不同层级的进程有着不同的运行环境,运行环境决定着系统进程的设计。在增强启动子系统能力方面有以下方面:
基础能力增强:进程启动、回收机制增强,维护命令统一以及插件化管理;
并行启动:最大化并行启动,为依赖资源提供同步机制,运行时进行资源获取;
按需启动:无访问不启动,减少常驻内存;
分组启动:可对服务进行灵活组装,提供整机不同的启动级别能力。
2.Init启动功能概述
2.1.基础能力的增强
进程启动,支持进程的selinux策略配置,扩展AccessToken设置,支持绑核配置;进程回收,支持进程频繁退出抑制机制;维护命令,统一init的维护命令,包括系统参数和进程管理;插件化管理,init部件与周边模块关联度高,通过插件化机制供其它模块扩展。
2.2.进程分组&并行启动
支持服务分组配置,如支持系统知名group,支持整机开机、重启、关机、待机、充电等模式;支持服务依赖管理,支持并行启动依赖同步机制。
2.3.按需启动
支持SA类进程按需启动,HDF类进程按需启动,socket类进程的按需启动;支持热插拔事件驱动进程按需启动;支持为按需启动定时启动、进程代持fd等辅助功能。

3.系统能力增强点分析
3.1.进程启动能力增强
进程启动时,支持在配置文件中配置服务进程的绑核、优先级、selinux策略加载以及AccessToken信息。
3.1.1.配置服务进程绑核能力
在服务的cfg配置文件中,配置绑核,例如param_watcher服务。系统启动之后通过taskset -p pid,查看服务绑核情况,例如 current affinity mask: 3,即表示param_watcher服务运行在两个cpu上切换。
“services” : [{
“name” : “param_watcher”,

“cpucore” : [0,1]
},
通过CJSON解析 cfg 文件,获取属性”cpucore”属性值的数组,然后通过接口CPU_SET设置进程的CPU.
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
在init,fork()服务子进程时设置CPU绑核。
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区

3.1.2.配置服务进程优先级
在服务cfg文件中配置进程的优先级,例如appspawn.cfg中配置"importance" : -20,即设置appspawn的优先级为-20。

 {
                "services" : [{
                "name" : "appspawn",
                "path" : ["/system/bin/appspawn"],
                "importance" : -20,
                "uid" : "root",
                "gid" : ["root"],
                "start-mode" : "boot"
                }
              ]
}

代码中通过CJSON解析cfg文件中”importance”属性,得到服务的优先级,同时通过SetImportantValue回调函数保存优先级属性。
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
在ServiceExec执行进程命令之前通过setpriority
设置服务的优先级。
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
3.1.3.服务的selinux策略加载
OpenHarmony正在不断完善selinux安全策略,后面对于服务的管控会更加严格。Init启动在服务cfg文件中提供配置进程的Selinux接口,例如updater_sa.cfg文件中配置
“secon” : “u:r:updater_sa:s0”。
{
“services” : [{
“name” : “updater_sa”,
“path” : [“/system/bin/sa_main”, “/system/profile/updater_sa.xml”],
“uid” : “system”,
“gid” : [“system”, “shell”],
“secon” : “u:r:updater_sa:s0”
}
]
}
通过JSON解析cfg文件中"secon"属性,获取服务的selinux值。
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
在init初始时,加载selinux LoadPolicy。
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
在init fork子进程时,通过SetSecon 设置服务的selinux。
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
3.1.4.配置服务进程AccessToken属性
在服务cfg文件中配置进程的AccessToken,即cfg文件中配置
“apl”: “xxx”,设置一串令牌。
通过JSON解析cfg文件中"apl"属性,获取服务的apl值。
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
在init fork 子进程的时候设置进程的AccessToken.
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
3.2.进程启动&回收能力增强
3.2.1.进程的启动流程

init启动系统服务进程时都是先fork再execv执行目标服务进程而完成启动。Fork的流程又细分为
pre-fork:即服务进程不需要真正的启动,只是由init做好服务的准备工作,服务被访问时拉起服务;
fork:只要fork成功,init就接着启动下一个进程,即使后面execv执行失败也忽略,最大承担并行启动服务;
execv:fork完成之后需要execv执行成功,才算服务启动完成;
service:在服务启动完成之后,通过setparameter 设置服务启动标志"startup.service.ctl.serviceName" 为SERVICE_STARTED。
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
3.2.2.子进程退出资源回收
init监听到任何子进程退出都需要waitpid回收该进程,避免出现僵尸进程。
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
3.2.3.设置服务启动特殊模式
通过在服务的cfg文件中配置Once、Disabled、Critical属性值设置服务启动的特殊方式。
Default:默认情况下服务退出之后,init会再次拉起服务;
Once:服务是单次启动模式,退出之后init不再拉起;
Disabled:服务是被禁用的,退出后也不会拉起;
Critical:服务失败后需要重新拉起,但是失败N次之后,系统就会重启,默认是4次。
常驻服务进程如果一直异常退出,为了避免频繁尝试拉起该服务,增加抑制机制,默认3秒内连续退出超过5次则不再自动拉起该服务。
核心服务进程如果一直异常退出,为了避免系统不可用,尝试系统重启;默认20秒内连续退出超过4次则不再自动拉起该服务。
例如 “critical” : [1, 1, 60], 代表有critical attribute,同时60秒内重启1次,就系统重启。通过GetCritical函数解析critical 属性,通过CalculateCrashTime函数判断是否需要重启服务,或是reboot系统。

OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
3.3.提供整机状态服务
3.3.1.整机状态

各系统服务进程启动后,还需要相应整机提供的重启、关机等请求(对应整机状态变化能够对进程进行相应处理stop、suspend、freeze等)。
重启、shutdown关机:关闭服务进程,通过stop命令关闭服务;
Suspend关机:STR带电低功耗关机,可快速开机,服务可选择的退出或清理资源;
Freeze关机:STD系统快照写到Disk,可完全掉电并快速开机。
通过reboot命令,设置 "startup.device.ctl"参数给外界提供当前整机的状态,系统服务进程可通过ParameterClient的watch机制监听整机的状态变化,处理自己的状态。
Reboot 命令:
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
3.3.2.服务可以通过start/stop来启动停止
通过以下命令可以启动或者停止服务。
start_service servicename --start service
stop_service servicename --stop service
service_control start servicename --start service
service_control stop servicename --stop service
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
最终通过SystemSetParameter(“ohos.ctl.start”, nameValue)启动服务,其中nameValue是服务名+服务的参数组合数组。
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
3.4.按需启动
3.4.1.SA进程按需启动

需要按需启动的SA服务,通过在cfg文件配置”dynamic” : true,设置此SA服务为按需启动,即init在start service的时候解析到此属性,不直接拉起服务;而是通过client端触发samgr拉起服务。
动态加载系统服务进程及SystemAbility, 系统进程无需开机启动,而是在SystemAbility被访问的时候按需拉起,并加载指定SystemAbility。继承SystemAbilityLoadCallbackStub类,并覆写OnLoadSystemAbilitySuccess(int32_t systemAbilityId, const sptr& remoteObject)、OnLoadSystemAbilityFail(int32_t systemAbilityId)方法。
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
调用samgr提供的动态加载接口LoadSystemAbility(int32_t systemAbilityId, const sptr& callback)。
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
Samgr通过调用init提供的ServiceControlWithExtra接口,拉起服务。
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
3.4.2.UHDF进程按需启动
同上SA服务的按需启动的分析,只是在HUDF服务中调用ServiceControlWithExtra接口,拉起服务。
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
3.4.3.socket进程按需启动
init在pre-fork阶段为socket类进程创建好socket,init中监听创建好的socket上的网络事件,socket上有报文事件后,init拉起socket进程进行报文处理。
socket进程无报文处理后,可以自动退出,退出后init回收该子进程并重新监听socket网络数据。
在服务cfg文件中添加”ondemand” : true 配置,设置socket服务为按需启动。

OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
在fork 子进程的时候,判断服务是ondemand的,则创建socket监听。
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
通过回调函数ProcessWatchEvent_处理socket按需启动的事件。
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
3.4.4.热插拔服务进程按需启动
配置ueventd.cfg配置文件中设备节点<parameter> 属性,例如,/dev/binder <parameter> 属性配置为 ohos.dev.binder,当设备节点被创建好,param设置ohos.dev.binder属性值为added。
在相应服务的cfg文件中,配置”job”为condition,如下
“condition” : “ohos.dev.binder=added”
即当条件满足时触发服务拉起。
3.4.5.定时拉起&fd代持
定时拉起:服务进程在退出前可根据业务需要预约下次启动的时间。
fd代持:按需启动进程可以保持退出前的fd状态句柄不丢失。按需启动进程退出前可发fd发送给init代持,再次启动后再获取fd。
在服务的cfg配置"timer_start" : 6 ,设置服务6秒后拉起。通过LE_CreateTimer创建定时器,定时时间到达时,触发回调函数,拉起服务。
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
创建fdhold的socket,注册event loop回调函数ProcessFdHoldEvent监听。
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
3.5.并行启动及依赖管理
begetd启动分三个阶段,pre-init和init阶段完成公共依赖部分;后续所有的服务都是并行化启动。服务启动的依赖包括Job和Service。
3.5.1.Job
所有的Job由init特权进程完成,可包括:设置全局环境变量,设置特权/proc, /sys节点参数等。
3.5.2.Service
Service依赖的前置条件可在启动脚本里指定Job完成。例如在service 中配置
“service”:
“jobs” : {
                “on-start” : “services:console”
            }
“job”:
{
            “name” : “services:console”,
            “cmds” : [
                “chmod 0773 /data/misc/trace”,
                “chmod 0775 /data/misc/wmtrace”
            ]
        }
即在fork子进程的时候执行job相关的命令。
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区

通过cfg文件设置服务的”start-mode”来管理正常启动还是并行启动。
“start-mode” : “boot”
“start-mode” : “normal”
“start-mode” : “condition”
其中boot、normal 模式是并行启动,service不写start-mode默认也是normal。Condition模式必须通过 start service 来拉起。
Start-mode通过注册钩子函数,通过trigger拉起服务。
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
3.6.分组管理
系统服务可以按照分组进行管理,设备级知名group用于完成整机的开机、待机、充电等功能。默认的整机开机是放到GROUP_BOOT中,GROUP_CHARING是充电模式。
以charging group举例说明。
配置device.charing.group.cfg 里面设置需要的jobs、services以及groups。
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
解析group 的cfg文件。
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
通过hash表保存group的配置。
通过cmdline获取当前的group 模式,从而启动进入不同的group,系统进入不同的模式。
OpenHarmony  release3.1版本启动子系统功能分析-开源基础软件社区
4.总结
Release3.1 版本在OpenHarmony2.0的基础上各方面能力都有所提升,性能和稳定性方面有所改善。Init组件中加入selinux配置,增强了系统的安全模式,按需启动模式节约系统的内存资源,并行启动增加了系统的启动效率,分组启动模式为后期系统进入不同状态模式提供有效的接口。总之OpenHarmony在开源社区中,通过大家的共同努力正在茁长成长,总有一天会长成苍天大树,枝繁叶茂,造福人类。

©著作权归作者所有,如需转载,请注明出处,否则将追究法律责任
已于2022-4-21 16:47:17修改
5
收藏 5
回复
举报
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源 去关联
    相关推荐