OpenHarmony恢复启动子系统init进程之参数空间配置

本文介绍了一种基于Trie树的数据结构来高效存储和管理系统参数的方法。详细解释了参数的分类,包括常量参数、常驻参数和临时参数,并介绍了参数来源如内核参数、os常量值等。同时,还探讨了自主访问控制(DAC)机制下参数的权限管理及触发参数的概念。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

参数由key和值构成,key 的格式由多重前缀构成。

const.postinstall.fstab.prefix=/system
const.secure=1
security.perf_harden=1
const.allow.mock.location=0
const.debuggable=1
const.build.characteristics=default
const.product.model=ohos
const.product.name="OpenHarmony 3.1 Release"
persist.sys.usb.config=hdc

参数物理空间使用的是一维数组存储每个参数,但是从逻辑上使用Trie树(前缀树)的数据结构存储,从根节点往下依次连成最终的key。这种数据结构提高了查找效率。

参数分类 

类别

前缀

说明

常量参数

const.

从赋值开始永远不会变更

常驻参数

persist.

可写并可持久化保存参数,重启后不会丢失。为保持一致,会有个定时器定期的批量保存到文件

临时参数

其他

可以随时修改,但是系统重启后参数丢失。

参数来源

类别

路径

说明

内核参数

/proc/cmdline

内核参数中部分参数转换成ohos.boot.xxx=valXXX系统参数

os常量值

/system/etc/param/ohos_const/*.para

os常量值

vendor参数值

/vendor/etc/param/*.para

厂商定义的参数文件,可覆盖系统参数值

系统参数

/system/etc/param/*.para

系统参数,如果跟厂商参数重复,忽略系统参数

/proc/cmdline

# cat /proc/cmdline                                                            
mem=640M console=ttyAMA0,115200 mmz=anonymous,0,0xA8000000,384M clk_ignore_unused rootdelay=10 hardware=Hi3516DV300 init=/init root=/dev/ram0 rw blkdevparts=mmcblk0:1M(boot),15M(kernel),20M(updater),10M(misc),3307M(system),256M(vendor),-(userdata) initrd=0x84000000,0x290e00

获取hardware,bootgroup,mem等参数值加入参数。

例如: ohos.boot.hardware=Hi3516DV300

参数文件 ohos.para

hw_sc.build.os.releasetype=Release

const.actionable_compatible_property.enabled=false
const.postinstall.fstab.prefix=/system
const.product.name="OpenHarmony 3.1 Release"
persist.sys.usb.config=hdc

参数文件 ohos.para.dac

const.actionable_compatible_property.enabled root:root:0777
const.postinstall.fstab.prefix root:root:0777
const.secure root:root:0777
security.perf_harden root:root:0777
const.allow.mock.location root:root:0777
const.debuggable root:root:0777
persist.sys.usb.config root:root:0777

DAC(Discretionary Access Control)自主访问控制方式管理

需要根据用户、组用户、读写权限等进行验证权限,才能到指定文件读取参数值。

可以通过参数路径为相同前缀的所有系统参数定义一类访问权限信息;DAC信息通过":"分三段来描述,分别为参数的user,group以及UGO规则信息。

UGO规则信息每一位的定义如下:

 跟文件权限不同的是,第三个比特表示watch权限。

功能

说明

get

获取系统参数的值

set

设置系统参数的值

wait

同步等待系统参数的值匹配,支持模糊匹配,例如: hd*, 则匹配hdc,hdi等等。“*”表示匹配任何值

watch

将一个参数加入监视队列,当参数发生变化,通知用户

trigger参数

将jobs、系统控制命令这些纳入trigger参数范围。

类型

特征

说明

BOOT

"pre-init", "boot", "early-init", "init", "early-init", "late-init", "post-init",

"fs", "early-fs", "post-fs", "late-fs", "early-boot", "post-fs-data",

"reboot", "suspend"

需要优先执行的jobs

PARAM

以param:为前缀的jobs

参数操作相关的命令,

 参数类型的jobs:

{
            "name" : "param:sys.sysctl.extra_free_kbytes=*",
            "condition" : "sys.sysctl.extra_free_kbytes=*",
            "cmds" : [
                "write /proc/sys/vm/extra_free_kbytes ${sys.sysctl.extra_free_kbytes}"
            ]
        }, {
            "name" : "param:sys.sysctl.tcp_def_init_rwnd=*",
            "condition" : "sys.sysctl.tcp_def_init_rwnd=*",
            "cmds" : [
                "write /proc/sys/net/ipv4/tcp_default_init_rwnd ${sys.sysctl.tcp_def_init_rwnd}"
            ]
        }, {
            "name" : "param:security.perf_harden=0",
            "condition" : "security.perf_harden=0",
            "cmds" : [
                "write /proc/sys/kernel/perf_event_paranoid 1",
                "write /proc/sys/kernel/perf_event_max_sample_rate ${debug.perf_event_max_sample_rate:-100000}",
                "write /proc/sys/kernel/perf_cpu_time_max_percent ${debug.perf_cpu_time_max_percent:-25}",
                "write /proc/sys/kernel/perf_event_mlock_kb ${debug.perf_event_mlock_kb:-516}"
            ]
        }

trigger参数根据类型在存储的时候,添加对应的前缀,方便与其他参数存储在Trie树中,方便查找。

#define SYS_POWER_CTRL "ohos.startup.powerctrl="   //电源控制
#define OHOS_CTRL_START "ohos.ctl.start="   //控制启动
#define OHOS_CTRL_STOP "ohos.ctl.stop="      //控制停止
#define OHOS_SERVICE_CTRL_PREFIX "ohos.servicectrl."   //服务控制
#define OHOS_BOOT "ohos.boot."    // boot 参数

<think>嗯,用户想了解从OpenHarmony 4.1升级到5.1的底层适配工作,这应该是个开发者或系统工程师在规划版本迁移。用户特意强调"底层适配",说明关注的是硬件和内核层面的改动,不是应用层开发。 从引用材料看,4.1到5.1的跨度不小,引用[2]提到过4.1升5.0.3的移植案例,引用[1]则提到5.0.2的SDK更新。不过用户需要的是5.1,可能需要结合官方文档推测变化。 核心适配点应该集中在几个方面: 首先是内核层,LiteOS-A内核升级肯定要重点关注,进程管理、内存分配这些基础机制变动会影响驱动兼容性。引用[2]里GD32H759的移植就涉及内核适配。 驱动框架也是重头戏,HDF的API变更在引用[1]提到过"深度优化",具体可能涉及GPIO、I2C这些基础接口。用户如果是做设备开发,这块要重点验证。 编译系统改动很大,引用[3]提到windows下新构建工具链,gn脚本和编译参数估计都有调整。引用[2]的GD32H759移植里就专门下载了新工具链。 另外安全机制升级容易被忽略,TSK框架引入的加密验证流程变化在引用[1]有暗示,但具体细节可能需要查5.1的release notes。 用户没提具体芯片平台,所以补充了通用建议:先看官方迁移指南,用新SDK编译现有代码。如果用户用的是Hi3861这类热门开发板,引用[2][3]的实操经验会很有参考价值。 最后列出的三个问题中,HDF兼容性可能是用户马上要面临的痛点,编译错误和启动失败则是移植初期常见问题。如果用户后续追问,可以结合具体芯片展开。</think>从 OpenHarmony 4.1 升级到 5.1 涉及底层架构的演进,需要进行多方面的适配工作,主要集中在以下核心模块和组件: --- ### 一、**内核层适配** 1. **内核升级与接口变更**: * OpenHarmony 5.1 通常基于更新的 LiteOS-A 内核版本(或支持 Linux Kernel 5.10+)。需要验证现有驱动、进程/线程管理、内存管理、IPC 等是否兼容新内核的 API 和行为。 * 检查内核配置 (`Kconfig`) 的差异,确保所需特性(如特定文件系统、网络协议栈特性、安全模块)被正确启用。 2. **HDF 驱动框架适配**: * **HDF 版本兼容性**:5.1 可能引入 HDF 框架的改进或新接口。需要检查现有驱动代码是否符合最新 HDF 规范,特别是驱动模型、设备服务发布、电源管理、GPIO/I2C/SPI/UART 等总线驱动接口[^1]。 * **新设备支持**:如果 5.1 引入了对新型号芯片或外设的官方支持,需评估是否需要集成或更新相关 HDF 驱动。 --- ### 二、**系统服务层适配** 1. **分布式子系统**: * 分布式软总线 (`dsoftbus`)、设备管理、数据管理等核心分布式能力在 5.1 中通常有显著增强。需要验证设备发现、连接建立、数据传输、安全认证等流程是否与 4.1 兼容,或需按新接口/协议调整[^1]。 2. **安全子系统**: * **应用权限模型**:权限定义、申请、授予、检查机制可能有更新,需调整应用或系统服务的权限配置。 * **设备认证与可信启动**:如果使用了设备认证 (`device_auth`) 或可信启动 (`startup_init`),需确认其配置、策略、密钥管理在新版本中的兼容性。 * **HUKS/HCS**:硬件密钥服务 (`huks`) 和硬件凭证服务 (`hcs`) 的接口或能力可能更新,影响加解密、证书存储等安全功能。 3. **多媒体子系统**: * 音频 (`audio`)、视频 (`video`)、相机 (`camera`) 的 HDI 接口 (`//drivers/peripheral`) 或服务框架 (`//foundation/multimedia`) 可能有变更,需适配驱动层对接和应用层调用。 4. **图形子系统**: * 显示 (`display`)、窗口 (`window`)、合成 (`composer`) 相关的 HDI 接口 (`//drivers/peripheral/display`) 或图形服务 (`//foundation/graphic`) 若有更新,会影响 UI 渲染和显示输出。 --- ### 三、**运行时与框架层适配** 1. **ArkUI 框架**: * OpenHarmony 5.1 强化了声明式 UI 开发范式。若应用基于旧的 JS UI 或 Java UI 框架,需评估迁移到 ArkUI (TypeScript/ETS) 的必要性和工作量。 * 检查 ArkUI 组件、布局、动画、事件处理等 API 的兼容性。 2. **系统能力 (System Capability, SysCap) 模型**: * 5.1 可能细化或调整了 SysCap 的定义。需确认设备 Profile (`//productdefine/common/device`) 中定义的 SysCap 集合是否满足应用需求,并确保应用按新模型声明其依赖[^1]。 --- ### 四、**编译构建系统适配** 1. **工具链升级**: * 升级到 5.1 要求的 Clang/LLVM、GCC、Python 等版本。检查编译脚本 (`build.sh`, `BUILD.gn`) 的兼容性。 * 确保 `prebuilts` (预编译工具链、库) 已更新至 5.1 版本 (`bash build/prebuilts_download.sh`)[^2][^3]。 2. **GN 与 Ninja 脚本**: * 仔细比对 `//build` 目录下的核心构建配置 (`*.gn`, `*.gni`),特别是产品定义 (`//productdefine`)、芯片适配层 (`//device`)、内核构建 (`//kernel`) 相关的脚本。调整路径、编译选项、依赖关系等[^2][^3][^4]。 3. **产品配置迁移**: * 将 4.1 的产品配置文件 (`//vendor/xxx/product/yyy/config.json`, `//productdefine/common/products/yyy.json`) 迁移到 5.1 的格式和位置。特别注意 `subsystems` 和 `components` 的配置项变化。 * 更新芯片适配层 (`//device/board/xxx`, `//device/soc/yyy`) 的构建配置,确保能正确链接到 5.1 的 SDK 和库[^2][^4]。 --- ### 五、**芯片/板级支持包 (BSP) 适配** 1. **启动引导 (Bootloader)**: * 验证 U-Boot 或 LiteOS Bootloader (L0) 是否支持 5.1 内核的启动参数、设备树 (DTS) 格式、内存映射等。 2. **设备树 (DTS) 更新**: * 根据内核版本升级,同步更新硬件描述文件 (`*.dts`, `*.dtsi`),确保外设地址、中断号、时钟、Pin Mux 等配置正确。 3. **外设驱动移植**: * 若芯片原厂或社区提供了针对 5.1 的更新驱动,优先集成。 * 若需自行移植,重点适配 GPIO、中断控制器 (GIC)、时钟 (PLL)、定时器 (PWM)、串口 (UART)、存储 (eMMC/SD/NOR/NAND)、网络 (ETH/WiFi/BT) 等基础驱动。 --- ### 六、**开发工具与环境** 1. **SDK 更新**: * 必须使用 OpenHarmony 5.1 Release 的 SDK (`//prebuilts/ohos-sdk`),替换掉 4.1 的 SDK。API 差异可能导致编译错误或运行时问题[^1][^3]。 2. **DevEco Device Tool/DevEco Studio**: * 升级到支持 OpenHarmony 5.1 的 IDE 版本,确保烧录、调试、性能分析等功能兼容新系统。 --- ### 升级适配建议流程 1. **查阅官方文档**: * 仔细阅读 [OpenHarmony 5.1 Release Notes](https://gitee.com/openharmony/docs/blob/master/zh-cn/release-notes/) 和 [API差异报告](https://gitee.com/openharmony/community/blob/master/zh/contribute/api-diff-report.md)。 2. **获取目标版本代码**: ```bash repo init -u https://gitee.com/openharmony/manifest -b refs/tags/OpenHarmony-v5.1-Release repo sync -c repo forall -c 'git lfs pull' # 引用[2][^4]的下载方式升级到5.1 ``` 3. **逐步迁移产品配置**: * 在 `//productdefine/common/products/` 下创建新产品的 `.json` 文件,参考 4.1 配置和 5.1 示例调整。 4. **编译验证**: * 使用新工具链编译基础系统 (`./build.sh --product-name your_product --ccache`),优先解决编译错误[^2][^3]。 5. **驱动与HDF适配**: * 在 `//device/board/your_vendor/your_board` 和 `//device/soc/your_soc_vendor` 下更新代码,适配 HDF 和内核变更。 6. **功能与稳定性测试**: * 重点测试启动流程、核心系统服务、外设功能、分布式能力、安全特性、功耗管理等。 --- **相关问题** 1. 如何解决 OpenHarmony 5.1 中 HDF 驱动兼容性问题? 2. 升级后遇到系统启动失败 (Kernel Panic) 应如何排查? 3. OpenHarmony 5.1 的分布式组网协议相比 4.1 有哪些主要改进? [^1]: Tuanjie 1.5.0 适配 OpenHarmony v5.0.2 Release,优化了开发效率与平台能力。 [^2]: GD32H759IMT6 移植示例展示了从 4.1 到 5.0.3 的源码下载、环境配置和编译流程。 [^3]: Windows 版编译构建工具链更新说明,强调环境配置对开发效率的影响。 [^4]: OpenHarmony 3.1 Release 的代码下载方法,适用于后续版本升级的场景。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值