社区编辑申请
注册/登录
OpenHarmony Release3.1版本启动子系统功能分析
系统 OpenHarmony
本文就3.1版本的init启动子系统模块,在启动引导系统服务方面进行分析。本文档是基于码云上release3.1分支代码进行分析。

​想了解更多内容,请访问:​

​51CTO和华为官方合作共建的鸿蒙技术社区​

​https://ost.51cto.com​

1、技术背景

OpenHarmony release3.1版本在2.0的基础之上不仅增加了功能,而且各模块组件的能力也有所增强,本文就3.1版本的init启动子系统模块,在启动引导系统服务方面进行分析。本文档是基于码云上release3.1分支代码进行分析。

启动子系统负责整个系统各个进程运行时环境的构建及进程引导,不同层级的进程有着不同的运行环境,运行环境决定着系统进程的设计。在增强启动子系统能力方面有以下方面:

  • 基础能力增强:进程启动、回收机制增强,维护命令统一以及插件化管理。
  • 并行启动:最大化并行启动,为依赖资源提供同步机制,运行时进行资源获取。
  • 按需启动:无访问不启动,减少常驻内存。
  • 分组启动:可对服务进行灵活组装,提供整机不同的启动级别能力。

2、Init启动功能概述

(1)基础能力的增强

进程启动,支持进程的selinux策略配置,扩展AccessToken设置,支持绑核配置;进程回收,支持进程频繁退出抑制机制;维护命令,统一init的维护命令,包括系统参数和进程管理;插件化管理,init部件与周边模块关联度高,通过插件化机制供其它模块扩展。

(2)进程分组&并行启动

支持服务分组配置,如支持系统知名group,支持整机开机、重启、关机、待机、充电等模式;支持服务依赖管理,支持并行启动依赖同步机制。

(3)按需启动

支持SA类进程按需启动,HDF类进程按需启动,socket类进程的按需启动;支持热插拔事件驱动进程按需启动;支持为按需启动定时启动、进程代持fd等辅助功能。

3、系统能力增强点分析

(1)进程启动能力增强

进程启动时,支持在配置文件中配置服务进程的绑核、优先级、selinux策略加载以及AccessToken信息。

配置服务进程绑核能力

在服务的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。

在init,fork()服务子进程时设置CPU绑核。

配置服务进程优先级

在服务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回调函数保存优先级属性。

在ServiceExec执行进程命令之前通过setpriority。

设置服务的优先级。

服务的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值。

在init初始时,加载selinux LoadPolicy。

在init fork子进程时,通过SetSecon 设置服务的selinux。

配置服务进程AccessToken属性

在服务cfg文件中配置进程的AccessToken,即cfg文件中配置。

“apl”: “xxx”,设置一串令牌。

通过JSON解析cfg文件中"apl"属性,获取服务的apl值。

在init fork 子进程的时候设置进程的AccessToken。

(2)进程启动&回收能力增强

进程的启动流程

init启动系统服务进程时都是先fork再execv执行目标服务进程而完成启动。Fork的流程又细分为

  • pre-fork:即服务进程不需要真正的启动,只是由init做好服务的准备工作,服务被访问时拉起服务。
  • fork:只要fork成功,init就接着启动下一个进程,即使后面execv执行失败也忽略,最大承担并行启动服务。
  • execv:fork完成之后需要execv执行成功,才算服务启动完成。
  • service:在服务启动完成之后,通过setparameter 设置服务启动标志"startup.service.ctl.serviceName" 为SERVICE_STARTED。

子进程退出资源回收

init监听到任何子进程退出都需要waitpid回收该进程,避免出现僵尸进程。

设置服务启动特殊模式

通过在服务的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系统。

(3)提供整机状态服务

整机状态

各系统服务进程启动后,还需要相应整机提供的重启、关机等请求(对应整机状态变化能够对进程进行相应处理stop、suspend、freeze等)。

  • 重启、shutdown关机:关闭服务进程,通过stop命令关闭服务。
  • Suspend关机:STR带电低功耗关机,可快速开机,服务可选择的退出或清理资源。
  • Freeze关机:STD系统快照写到Disk,可完全掉电并快速开机。

通过reboot命令,设置 "startup.device.ctl"参数给外界提供当前整机的状态,系统服务进程可通过ParameterClient的watch机制监听整机的状态变化,处理自己的状态。

Reboot 命令:

服务可以通过start/stop来启动停止

通过以下命令可以启动或者停止服务。

start_service servicename --start service
stop_service servicename --stop service
service_control start servicename --start service
service_control stop servicename --stop service

最终通过SystemSetParameter(“ohos.ctl.start”, nameValue)启动服务,其中nameValue是服务名+服务的参数组合数组。

(4)按需启动

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)方法。

调用samgr提供的动态加载接口LoadSystemAbility(int32_t systemAbilityId, const sptr& callback)。

Samgr通过调用init提供的ServiceControlWithExtra接口,拉起服务。

UHDF进程按需启动

同上SA服务的按需启动的分析,只是在HUDF服务中调用ServiceControlWithExtra接口,拉起服务。

socket进程按需启动

init在pre-fork阶段为socket类进程创建好socket,init中监听创建好的socket上的网络事件,socket上有报文事件后,init拉起socket进程进行报文处理。

socket进程无报文处理后,可以自动退出,退出后init回收该子进程并重新监听socket网络数据。

在服务cfg文件中添加”ondemand” : true 配置,设置socket服务为按需启动。

在fork 子进程的时候,判断服务是ondemand的,则创建socket监听。

通过回调函数ProcessWatchEvent_处理socket按需启动的事件。

热插拔服务进程按需启动

配置ueventd.cfg配置文件中设备节点 属性,例如,/dev/binder 属性配置为 ohos.dev.binder,当设备节点被创建好,param设置ohos.dev.binder属性值为added。

在相应服务的cfg文件中,配置”job”为condition,如下:

“condition” : “ohos.dev.binder=added”

即当条件满足时触发服务拉起。

定时拉起&fd代持

定时拉起:服务进程在退出前可根据业务需要预约下次启动的时间。

fd代持:按需启动进程可以保持退出前的fd状态句柄不丢失。按需启动进程退出前可发fd发送给init代持,再次启动后再获取fd。

在服务的cfg配置"timer_start" : 6 ,设置服务6秒后拉起。通过LE_CreateTimer创建定时器,定时时间到达时,触发回调函数,拉起服务。

创建fdhold的socket,注册event loop回调函数ProcessFdHoldEvent监听。

(3)并行启动及依赖管理

begetd启动分三个阶段,pre-init和init阶段完成公共依赖部分;后续所有的服务都是并行化启动。服务启动的依赖包括Job和Service。

Job

所有的Job由init特权进程完成,可包括:设置全局环境变量,设置特权/proc, /sys节点参数等。

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相关的命令。

通过cfg文件设置服务的”start-mode”来管理正常启动还是并行启动。

“start-mode” : “boot”
“start-mode” : “normal”
“start-mode” : “condition”

其中boot、normal 模式是并行启动,service不写start-mode默认也是normal。Condition模式必须通过 start service 来拉起。

Start-mode通过注册钩子函数,通过trigger拉起服务。

(6)分组管理

系统服务可以按照分组进行管理,设备级知名group用于完成整机的开机、待机、充电等功能。默认的整机开机是放到GROUP_BOOT中,GROUP_CHARING是充电模式。

以charging group举例说明。

配置device.charing.group.cfg 里面设置需要的jobs、services以及groups。

解析group 的cfg文件。

通过hash表保存group的配置。

通过cmdline获取当前的group 模式,从而启动进入不同的group,系统进入不同的模式。

4、总结

Release3.1 版本在OpenHarmony2.0的基础上各方面能力都有所提升,性能和稳定性方面有所改善。Init组件中加入selinux配置,增强了系统的安全模式,按需启动模式节约系统的内存资源,并行启动增加了系统的启动效率,分组启动模式为后期系统进入不同状态模式提供有效的接口。总之OpenHarmony在开源社区中,通过大家的共同努力正在茁长成长,总有一天会长成苍天大树,枝繁叶茂,造福人类。

​想了解更多内容,请访问:​

​51CTO和华为官方合作共建的鸿蒙技术社区​

​https://ost.51cto.com​

责任编辑:jianghua 来源: 鸿蒙社区

同话题下的热门内容

HarmonyOS - HDC命令与ADB命令使用对比OHOS构建自定义服务实战啃论文俱乐部—数据密集型应用内存压缩HarmonyOS - 自定义组件之计时器基于OpenHarmony3.1的购物车应用的实现HarmonyOS - 方舟开发框架ArkUI 流光按钮效果OpenHarmony3.1-Ace-Formcomponent源码解析OpenHarmony HiSysEvent打点调用实践(L2)

编辑推荐

HarmonyOS 2.0鸿蒙第二期开发者Beta公测申请指南HarmonyOS LYEVK-3861开发板播放《蜜雪冰城》鸿蒙HarmonyOS分布式软总线:构建低时延、高带宽的多设备虚拟网络华为HarmonyOS的强势突围: 直面物联网迷宫的蓄力进击鸿蒙HarmonyOS2.0发布会现场回忆录
我收藏的内容
点赞
收藏

51CTO技术栈公众号