OpenHarmony之内核层解析~

OpenHarmony简介

技术架构

OpenHarmony整体遵从分层设计，从下向上依次为：内核层、系统服务层、框架层和应用层。系统功能按照“系统 > 子系统 > 组件”逐级展开，在多设备部署场景下，支持根据实际需求裁剪某些非必要的组件。OpenHarmony技术架构如下所示：

技术特性

硬件互助，资源共享

主要通过下列模块达成

• 分布式软总线

  分布式软总线是多设备终端的统一基座，为设备间的无缝互联提供了统一的分布式通信能力，能够快速发现并连接设备，高效地传输任务和数据。

• 分布式数据管理

  分布式数据管理位于基于分布式软总线之上的能力，实现了应用程序数据和用户数据的分布式管理。

• 分布式任务调度

  分布式任务调度基于分布式软总线、分布式数据管理、分布式Profile等技术特性，构建统一的分布式服务管理（发现、同步、注册、调用）机制，支持对跨设备的应用进行远程启动、远程调用、绑定/解绑、以及迁移等操作，能够根据不同设备的能力、位置、业务运行状态、资源使用情况并结合用户的习惯和意图，选择最合适的设备运行分布式任务

• 设备虚拟化

  分布式设备虚拟化平台可以实现不同设备的资源融合、设备管理、数据处理，将周边设备作为手机能力的延伸，共同形成一个超级虚拟终端。

一次开发，多端部署

OpenHarmony提供用户程序框架、Ability框架以及UI框架，多终端软件平台API具备一致性，确保用户程序的运行兼容性。一次开发、多端部署。

统一OS，弹性部署

OpenHarmony通过组件化和组件弹性化等设计方法，做到硬件资源的可大可小，在多种终端设备间，按需弹性部署，全面覆盖了ARM、RISC-V、x86等各种CPU，从百KiB到GiB级别的RAM。

系统类型

OpenHarmony支持如下几种系统类型：

类型	处理器	最小内存	能力
轻量系统（mini system）	MCU类处理器（例如Arm Cortex-M、RISC-V 32位的设备）	128KiB	提供多种轻量级网络协议，轻量级的图形框架，以及丰富的IOT总线读写部件等。
小型系统（small system）	应用处理器（例如Arm Cortex-A的设备）	1MiB	提供更高的安全能力、标准的图形框架、视频编解码的多媒体能力。
标准系统（standard system）	应用处理器（例如Arm Cortex-A的设备）	128MiB	提供增强的交互能力、3D GPU以及硬件合成能力、更多控件以及动效更丰富的图形能力、完整的应用框架。

内核层

• 内核子系统： 采用多内核（Linux内核或者LiteOS）设计，支持针对不同资源受限设备选用适合的OS内核。内核抽象层（KAL，Kernel Abstract Layer）通过屏蔽多内核差异，对上层提供基础的内核能力，包括进程/线程管理、内存管理、文件系统、网络管理和外设管理等。

• 驱动子系统： 驱动框架（HDF）是系统硬件生态开放的基础，提供统一外设访问能力和驱动开发、管理框架。 OpenHarmony驱动子系统采用C面向对象编程模型构建，通过平台解耦、内核解耦，兼容不同内核，提供了归一化的驱动平台底座。

内核子系统

OpenHarmony针对不同量级的系统，分别使用了不同形态的内核，分别为LiteOS和Linux。

系统级别	轻量系统	小型系统	标准系统
LiteOS	√	√	×
Linux	×	√	√

LiteOS

OpenHarmony LiteOS内核是面向IoT领域的实时操作系统内核，基于Huawei LiteOS内核演进发展而来，包含LiteOS-M和LiteOS-A两类内核。

• LiteOS-M内核面向的MCU一般是百K级内存，可支持MPU（Memory Protection Unit）隔离，类似FreeRTOS或ThreadX等；
• LiteOS-A内核面向设备一般是M级内存，可支持MMU（Memory Management Unit）隔离，类似Zircon或Darwin等。

LiteOS-M

LiteOS-M内核架构包含硬件相关层和硬件无关层。
硬件相关层按不同编译工具链、芯片架构分类，提供统一的HAL接口；
硬件无关层，其中基础内核模块提供基础能力，扩展模块提供网络、文件系统等组件能力，还提供错误处理、调测等能力，KAL模块提供统一的标准接口。

注：ARM Cortex? 微控制器软件接口标准(CMSIS：Cortex Microcontroller Software Interface Standard) 是 Cortex-M 处理器系列的与供应商无关的硬件抽象层

LiteOS-A

LiteOS-A内核重要的新特性如下：

• 新增了丰富的内核机制， 新增虚拟内存、系统调用、多核、轻量级IPC、DAC（Discretionary Access Control，自主访问控制）等机制，丰富了内核能力；新增支持多进程，使得应用之间内存隔离、相互不影响

• 支持1200+标准POSIX接口 更加全面的支持POSIX标准接口，使得应用软件易于开发和移植

Linux

OpenHarmony 中Linux内核从LTS版本中选择合适的版本作为内核的基础版本，目前已完成对Linux-4.19及Linux-5.10的适配及支持，4.19已经处于维护周期

下面是 Linux 内核适配层的目录结构:

drivers/hdf_core/adapter/khdf/linux
├── manager               #linux内核下启动适配启动HDF框架代码
├── model                 #驱动模型适配linux代码
│   ├── audio
│   ├── camera
│   ├── display
│   ├── input
│   ├── misc              #杂项驱动模型,包括dsoftbus、light、vibrator等
│   ├── network           #网络驱动模型,包括wifi、bt等
│   ├── sensor
│   ├── storage
│   └── usb
├── network               #适配linux内核网络代码
├── osal                  #适配linux内核的posix接口
├── platform              #平台设备接口适配linux内核代码
│   ├── adc
│   ├── emmc
│   ├── fwk
│   ├── gpio
│   ├── i2c
│   ├── mipi_csi
│   ├── mipi_dsi
│   ├── mmc
│   ├── pwm
│   ├── regulator
│   ├── rtc
│   ├── sdio
│   ├── spi
│   ├── uart
│   └── watchdog        
├── test                  #linux内核测试用例
└── utils                 #linux内核下编译配置解析代码的编译脚本

内核增强特性

OpenHarmony 针对 linux 内核做了以下增强:

• Enhanced SWAP 特性
• 关联线程组调度
• CPU 轻量级隔离
• New IP内核协议栈
• XPM（eXecutable Permission Manager）模块

这些 Linux 内核增强特性,是否对我们现在的内核优化有啥借鉴意义?

Patch合入流程

主要是按照kernel.mk中对应的patch路径规则及命名规则，合入相应补丁

1. 合入不同内核版本对应的HDF内核补丁：

    $(OHOS_BUILD_HOME)/drivers/hdf_core/adapter/khdf/linux/patch_hdf.sh $(OHOS_BUILD_HOME) $(KERNEL_SRC_TMP_PATH) $(KERNEL_PATCH_PATH) $(DEVICE_NAME)

2. 合入芯片平台驱动补丁，以Hi3516DV300为例：

    DEVICE_PATCH_DIR := $(OHOS_BUILD_HOME)/kernel/linux/patches/${KERNEL_VERSION}/$(DEVICE_NAME)_patch
    DEVICE_PATCH_FILE := $(DEVICE_PATCH_DIR)/$(DEVICE_NAME).patch

3. 修改自己所需要编译的config：

    KERNEL_CONFIG_PATH := $(OHOS_BUILD_HOME)/kernel/linux/config/${KERNEL_VERSION}
    DEFCONFIG_FILE := $(DEVICE_NAME)_$(BUILD_TYPE)_defconfig

#### HCK

HCK（OpenHarmony Common Kernel）内核解耦框架。该框架为最新的v4.0 Beta版本引入，为开发者提供了整套插桩、注册、调用接口，减少对内核的侵入修改，统一解耦框架，插桩接口可在多平台间通用，使三方内核特性在不侵入或少侵入内核仓的情况下合入社区

HCK定义、注册、调用接口及流程图：

目前还只有 xpm、newip模块使用

直接合入内核仓或适用patch方法，相比有哪些弊端？维护，移植

KAL

内核抽象层（KAL，Kernel Abstract Layer）通过屏蔽多内核差异，对上层提供基础的内核能力，包括进程/线程管理、内存管理、文件系统、网络管理和外设管理等

Linux内核中操作系统抽象层（OSAL，Operating System Abstraction Layer）部分：

drivers/hdf_core/adapter/khdf/linux/osal/
├── include
│   ├── hdf_log_adapter.h
│   ├── hdf_types.h
│   ├── osal_atomic_def.h
│   ├── osal_cdev_adapter.h
│   ├── osal_io_adapter.h
│   ├── osal_math.h
│   └── osal_uaccess.h
├── Makefile
└── src
    ├── Makefile
    ├── osal_cdev.c
    ├── osal_deal_log_format.c
    ├── osal_file.c
    ├── osal_firmware.c
    ├── osal_irq.c
    ├── osal_mem.c
    ├── osal_mutex.c
    ├── osal_sem.c
    ├── osal_spinlock.c
    ├── osal_thread.c
    ├── osal_time.c
    ├── osal_timer.c
    └── osal_workqueue.c

驱动子系统

OpenHarmony驱动子系统采用C面向对象编程模型构建，通过平台解耦、内核解耦，兼容不同内核，提供了归一化的驱动平台底座，旨在为开发者提供更精准、更高效的开发环境，力求做到一次开发，多系统部署。

驱动架构

HDF（Hardware Driver Foundation）驱动框架，为驱动开发者提供驱动框架能力，包括驱动加载、驱动服务管理和驱动消息机制。
HDF驱动框架架构如下图所示:

HDF驱动架构主要组成部分：

• HDI层： (Hardware Device Interface，硬件设备统一接口),通过规范化的设备接口标准，为系统提供统一、稳定的硬件设备操作接口。

• HDF驱动框架： 提供统一的硬件资源管理、驱动加载管理、设备节点管理、设备电源管理以及驱动服务模型等功能，需要包含设备管理、服务管理、DeviceHost、PnPManager等模块。

• 统一的配置界面： 支持硬件资源的抽象描述，屏蔽硬件差异，可以支撑开发者开发出与配置信息不绑定的通用驱动代码，提升开发及迁移效率，并可通过HC-Gen等工具快捷生成配置文件。

• 操作系统抽象层： 提供统一封装的内核操作相关接口，屏蔽不同系统操作差异，包含内存、锁、线程、信号量等接口。

• 平台驱动： 为外设驱动提供硬件（如：I2C/SPI/UART总线等平台资源）操作统一接口，同时对硬件操作进行统一的适配接口抽象以便于不同平台迁移。

• 外设驱动模型： 面向外设驱动，提供常见的驱动抽象模型。

驱动开发

平台驱动

这里的平台设备，泛指I2C/UART等总线、以及GPIO/RTC等特定硬件资源。

平台驱动框架提供如下特性：

• 统一的平台设备访问接口（向上）：对平台设备操作接口进行统一封装，屏蔽不同SoC平台硬件差异以及不同OS形态差异，为系统及外设驱动提供标准的平台设备访问接口
• 统一的平台驱动适配接口（向下）：为平台设备驱动提供统一的适配接口，使其只关注自身硬件的控制，而不必关注设备管理及公共业务流程。
• 提供设备注册、管理、访问控制等与SoC无关的公共能力。

目前支持的设备类型包括但不限于：ADC、DAC、GPIO、HDMI、I2C、I3C、MIPI_CSI、MIPI_DSI、MMC、Pin、PWM、Regulator、RTC、SDIO、SPI、UART、WatchDog等。

外设驱动

在HDF驱动框架及平台驱动框架的基础上，提供标准化的外设器件驱动，可以减少重复开发；提供统一的外设驱动抽象模型，屏蔽驱动与不同系统组件间的交互，使得驱动更具备通用性。

目前支持的外设设备类型包括但不限于：Audio、Camera、Codec、Face_auth、Fingerprint_auth、LCD、Light、Motion、Pin_auth、Sensor、Touchscreen、USB、User_auth、Vibrator、WLAN等。

驱动架构代码说明

仓库路径	仓库内容
drivers/hdf_core/framework	HDF框架、平台驱动框架、驱动模型等平台无关化的公共框架
drivers/hdf_core/adapter/khdf	提供驱动框架对LiteOS-M、LiteOS-A内核、Linux等所有内核依赖适配
drivers/hdf_core/adapter/uhdf	提供用户态驱动接口对系统依赖适配
drivers/hdf_core/adapter/uhdf2	提供用户态驱动框架对系统依赖适配
drivers/peripheral	Display、Input、Sensor、WLAN、Audio、Camera等外设模块硬件抽象层。
drivers/interface	Display、Input、Sensor、WLAN、Audio、Camera等外设模块HDI接口定义。
drivers/external_device_manager	扩展外部设备管理框架

思考

• 为啥大费力气单独弄一套HDF驱动框架？为了上层的大一统？不同内核，不同硬件平台之间的迁移？ 统一，多端
• KAL+HDF，微内核的雏形？为后面引入微内核做准备？
• 有什么好处优势？KAL+独立的HDF驱动框架，分层解耦，驱动模型抽象，最小化修改最底层硬件适配，增加开发适配通用性，提高开发适配效率
• HCK，减少对社区内核侵入性，我们是否可以借鉴？
• 桌面系统内核一定非得是Linux内核？与内核解耦

为了能让大家更好的学习鸿蒙 (Harmony OS) 开发技术，这边特意整理了《鸿蒙 (Harmony OS)开发学习手册》（共计890页），希望对大家有所帮助：https://qr21.cn/FV7h05

《鸿蒙 (Harmony OS)开发学习手册》

入门必看：https://qr21.cn/FV7h05

1. 应用开发导读(ArkTS)
2. 应用开发导读(Java)

HarmonyOS 概念：https://qr21.cn/FV7h05

1. 系统定义
2. 技术架构
3. 技术特性
4. 系统安全

如何快速入门：https://qr21.cn/FV7h05

1. 基本概念
2. 构建第一个ArkTS应用
3. 构建第一个JS应用
4. ……

开发基础知识：https://qr21.cn/FV7h05

1. 应用基础知识
2. 配置文件
3. 应用数据管理
4. 应用安全管理
5. 应用隐私保护
6. 三方应用调用管控机制
7. 资源分类与访问
8. 学习ArkTS语言
9. ……

基于ArkTS 开发：https://qr21.cn/FV7h05

1. Ability开发
2. UI开发
3. 公共事件与通知
4. 窗口管理
5. 媒体
6. 安全
7. 网络与链接
8. 电话服务
9. 数据管理
10. 后台任务(Background Task)管理
11. 设备管理
12. 设备使用信息统计
13. DFX
14. 国际化开发
15. 折叠屏系列
16. ……