OpenHarmony之內核層解析~

OpenHarmony簡介

技術架構

OpenHarmony整體遵從分層設計，從下向上依次為：內核層、系統(tǒng)服務層、框架層和應用層。系統(tǒng)功能按照“系統(tǒng) > 子系統(tǒng) > 組件”逐級展開，在多設備部署場景下，支持根據實際需求裁剪某些非必要的組件。OpenHarmony技術架構如下所示：

技術特性

硬件互助，資源共享

主要通過下列模塊達成

  • 分布式軟總線

    分布式軟總線是多設備終端的統(tǒng)一基座，為設備間的無縫互聯(lián)提供了統(tǒng)一的分布式通信能力，能夠快速發(fā)現(xiàn)并連接設備，高效地傳輸任務和數據。

  • 分布式數據管理

    分布式數據管理位于基于分布式軟總線之上的能力，實現(xiàn)了應用程序數據和用戶數據的分布式管理。

  • 分布式任務調度

    分布式任務調度基于分布式軟總線、分布式數據管理、分布式Profile等技術特性，構建統(tǒng)一的分布式服務管理（發(fā)現(xiàn)、同步、注冊、調用）機制，支持對跨設備的應用進行遠程啟動、遠程調用、綁定/解綁、以及遷移等操作，能夠根據不同設備的能力、位置、業(yè)務運行狀態(tài)、資源使用情況并結合用戶的習慣和意圖，選擇最合適的設備運行分布式任務

  • 設備虛擬化

    分布式設備虛擬化平臺可以實現(xiàn)不同設備的資源融合、設備管理、數據處理，將周邊設備作為手機能力的延伸，共同形成一個超級虛擬終端。

一次開發(fā)，多端部署

OpenHarmony提供用戶程序框架、Ability框架以及UI框架，多終端軟件平臺API具備一致性，確保用戶程序的運行兼容性。一次開發(fā)、多端部署。

統(tǒng)一OS，彈性部署

OpenHarmony通過組件化和組件彈性化等設計方法，做到硬件資源的可大可小，在多種終端設備間，按需彈性部署，全面覆蓋了ARM、RISC-V、x86等各種CPU，從百KiB到GiB級別的RAM。

系統(tǒng)類型

OpenHarmony支持如下幾種系統(tǒng)類型：

類型 處理器 最小內存 能力
輕量系統(tǒng)（mini system） MCU類處理器（例如Arm Cortex-M、RISC-V 32位的設備） 128KiB 提供多種輕量級網絡協(xié)議，輕量級的圖形框架，以及豐富的IOT總線讀寫部件等。
小型系統(tǒng)（small system） 應用處理器（例如Arm Cortex-A的設備） 1MiB 提供更高的安全能力、標準的圖形框架、視頻編解碼的多媒體能力。
標準系統(tǒng)（standard system） 應用處理器（例如Arm Cortex-A的設備） 128MiB 提供增強的交互能力、3D GPU以及硬件合成能力、更多控件以及動效更豐富的圖形能力、完整的應用框架。

內核層

  • 內核子系統(tǒng)： 采用多內核（Linux內核或者LiteOS）設計，支持針對不同資源受限設備選用適合的OS內核。內核抽象層（KAL，Kernel Abstract Layer）通過屏蔽多內核差異，對上層提供基礎的內核能力，包括進程/線程管理、內存管理、文件系統(tǒng)、網絡管理和外設管理等。

  • 驅動子系統(tǒng)： 驅動框架（HDF）是系統(tǒng)硬件生態(tài)開放的基礎，提供統(tǒng)一外設訪問能力和驅動開發(fā)、管理框架。 OpenHarmony驅動子系統(tǒng)采用C面向對象編程模型構建，通過平臺解耦、內核解耦，兼容不同內核，提供了歸一化的驅動平臺底座。

內核子系統(tǒng)

OpenHarmony針對不同量級的系統(tǒng)，分別使用了不同形態(tài)的內核，分別為LiteOS和Linux。

系統(tǒng)級別 輕量系統(tǒng) 小型系統(tǒng) 標準系統(tǒng)
LiteOS √ √ ×
Linux × √ √

LiteOS

OpenHarmony LiteOS內核是面向IoT領域的實時操作系統(tǒng)內核，基于Huawei LiteOS內核演進發(fā)展而來，包含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內核架構包含硬件相關層和硬件無關層。
硬件相關層按不同編譯工具鏈、芯片架構分類，提供統(tǒng)一的HAL接口；
硬件無關層，其中基礎內核模塊提供基礎能力，擴展模塊提供網絡、文件系統(tǒng)等組件能力，還提供錯誤處理、調測等能力，KAL模塊提供統(tǒng)一的標準接口。

注：ARM Cortex? 微控制器軟件接口標準(CMSIS：Cortex Microcontroller Software Interface Standard) 是 Cortex-M 處理器系列的與供應商無關的硬件抽象層

LiteOS-A

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

  • 新增了豐富的內核機制， 新增虛擬內存、系統(tǒng)調用、多核、輕量級IPC、DAC（Discretionary Access Control，自主訪問控制）等機制，豐富了內核能力；新增支持多進程，使得應用之間內存隔離、相互不影響

  • 支持1200+標準POSIX接口 更加全面的支持POSIX標準接口，使得應用軟件易于開發(fā)和移植

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 特性
  • 關聯(lián)線程組調度
  • CPU 輕量級隔離
  • New IP內核協(xié)議棧
  • XPM（eXecutable Permission Manager）模塊

這些 Linux 內核增強特性,是否對我們現(xiàn)在的內核優(yōu)化有啥借鑒意義?

Patch合入流程

主要是按照kernel.mk中對應的patch路徑規(guī)則及命名規(guī)則，合入相應補丁

  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)
  1. 合入芯片平臺驅動補丁，以Hi3516DV300為例：
    DEVICE_PATCH_DIR := $(OHOS_BUILD_HOME)/kernel/linux/patches/${KERNEL_VERSION}/$(DEVICE_NAME)_patch
    DEVICE_PATCH_FILE := $(DEVICE_PATCH_DIR)/$(DEVICE_NAME).patch
  1. 修改自己所需要編譯的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版本引入，為開發(fā)者提供了整套插樁、注冊、調用接口，減少對內核的侵入修改，統(tǒng)一解耦框架，插樁接口可在多平臺間通用，使三方內核特性在不侵入或少侵入內核倉的情況下合入社區(qū)

HCK定義、注冊、調用接口及流程圖：

目前還只有 xpm、newip模塊使用

直接合入內核倉或適用patch方法，相比有哪些弊端？維護，移植

KAL

內核抽象層（KAL，Kernel Abstract Layer）通過屏蔽多內核差異，對上層提供基礎的內核能力，包括進程/線程管理、內存管理、文件系統(tǒng)、網絡管理和外設管理等

Linux內核中操作系統(tǒng)抽象層（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

驅動子系統(tǒng)

OpenHarmony驅動子系統(tǒng)采用C面向對象編程模型構建，通過平臺解耦、內核解耦，兼容不同內核，提供了歸一化的驅動平臺底座，旨在為開發(fā)者提供更精準、更高效的開發(fā)環(huán)境，力求做到一次開發(fā)，多系統(tǒng)部署。

驅動架構

HDF（Hardware Driver Foundation）驅動框架，為驅動開發(fā)者提供驅動框架能力，包括驅動加載、驅動服務管理和驅動消息機制。
HDF驅動框架架構如下圖所示:

HDF驅動架構主要組成部分：

  • HDI層： (Hardware Device Interface，硬件設備統(tǒng)一接口),通過規(guī)范化的設備接口標準，為系統(tǒng)提供統(tǒng)一、穩(wěn)定的硬件設備操作接口。

  • HDF驅動框架： 提供統(tǒng)一的硬件資源管理、驅動加載管理、設備節(jié)點管理、設備電源管理以及驅動服務模型等功能，需要包含設備管理、服務管理、DeviceHost、PnPManager等模塊。

  • 統(tǒng)一的配置界面： 支持硬件資源的抽象描述，屏蔽硬件差異，可以支撐開發(fā)者開發(fā)出與配置信息不綁定的通用驅動代碼，提升開發(fā)及遷移效率，并可通過HC-Gen等工具快捷生成配置文件。

  • 操作系統(tǒng)抽象層： 提供統(tǒng)一封裝的內核操作相關接口，屏蔽不同系統(tǒng)操作差異，包含內存、鎖、線程、信號量等接口。

  • 平臺驅動： 為外設驅動提供硬件（如：I2C/SPI/UART總線等平臺資源）操作統(tǒng)一接口，同時對硬件操作進行統(tǒng)一的適配接口抽象以便于不同平臺遷移。

  • 外設驅動模型： 面向外設驅動，提供常見的驅動抽象模型。

驅動開發(fā)

平臺驅動

這里的平臺設備，泛指I2C/UART等總線、以及GPIO/RTC等特定硬件資源。

平臺驅動框架提供如下特性：

  • 統(tǒng)一的平臺設備訪問接口（向上）：對平臺設備操作接口進行統(tǒng)一封裝，屏蔽不同SoC平臺硬件差異以及不同OS形態(tài)差異，為系統(tǒng)及外設驅動提供標準的平臺設備訪問接口
  • 統(tǒng)一的平臺驅動適配接口（向下）：為平臺設備驅動提供統(tǒng)一的適配接口，使其只關注自身硬件的控制，而不必關注設備管理及公共業(yè)務流程。
  • 提供設備注冊、管理、訪問控制等與SoC無關的公共能力。

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

外設驅動

在HDF驅動框架及平臺驅動框架的基礎上，提供標準化的外設器件驅動，可以減少重復開發(fā)；提供統(tǒng)一的外設驅動抽象模型，屏蔽驅動與不同系統(tǒng)組件間的交互，使得驅動更具備通用性。

目前支持的外設設備類型包括但不限于：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 提供用戶態(tài)驅動接口對系統(tǒng)依賴適配
drivers/hdf_core/adapter/uhdf2 提供用戶態(tài)驅動框架對系統(tǒng)依賴適配
drivers/peripheral Display、Input、Sensor、WLAN、Audio、Camera等外設模塊硬件抽象層。
drivers/interface Display、Input、Sensor、WLAN、Audio、Camera等外設模塊HDI接口定義。
drivers/external_device_manager 擴展外部設備管理框架

思考

  • 為啥大費力氣單獨弄一套HDF驅動框架？為了上層的大一統(tǒng)？不同內核，不同硬件平臺之間的遷移？ 統(tǒng)一，多端
  • KAL+HDF，微內核的雛形？為后面引入微內核做準備？
  • 有什么好處優(yōu)勢？KAL+獨立的HDF驅動框架，分層解耦，驅動模型抽象，最小化修改最底層硬件適配，增加開發(fā)適配通用性，提高開發(fā)適配效率
  • HCK，減少對社區(qū)內核侵入性，我們是否可以借鑒？
  • 桌面系統(tǒng)內核一定非得是Linux內核？與內核解耦
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
【社區(qū)內容提示】社區(qū)部分內容疑似由AI輔助生成，瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明：文章內容（如有圖片或視頻亦包括在內）由作者上傳并發(fā)布，文章內容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務。

相關閱讀更多精彩內容

友情鏈接更多精彩內容