OpenHarmony简介

技术架构

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

技术特性

硬件互助，资源共享

主要通过下列模块达成

• 分布式软总线

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

• 分布式数据管理

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

• 分布式任务调度

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

• 设备虚拟化

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

一次开发，多端部署

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

统一OS，弹性部署

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

系统类型

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

内核层

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

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

内核子系统

OpenHarmony针对不同量级的系统，分别使用了不同形态的内核，分别为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等。

驱动架构代码说明

思考

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