OpenHarmony系統(tǒng)HDF驅動框架概述

OpenAtom OpenHarmony（以下簡稱“OpenHarmony”）系統(tǒng) HDF 驅動框架采用 C 語言面向對象編程模型構建，通過平臺解耦、內核解耦，來達到兼容不同內核，統(tǒng)一平臺底座的目的，從而幫助開發(fā)者實現驅動一次開發(fā)，多系統(tǒng)部署的效果。

為了達成這個目標， OpenHarmony 系統(tǒng) HDF 驅動框架提供了：

操作系統(tǒng)適配層（OSAL，Operating System Abstraction Layer）：對內核操作相關接口進行統(tǒng)一封裝，屏蔽不同系統(tǒng)操作接口。

平臺驅動接口：提供 Board 部分驅動（例如，I2C/SPI/UART 總線等平臺資源）支持，同時對 Board 硬件操作進行統(tǒng)一的適配接口抽象，方便開發(fā)者只需開發(fā)新硬件抽象接口，即可獲得新增 Board 部分驅動支持。

驅動模型：面向器件驅動，提供常見的驅動抽象模型，主要達成兩個目的。

1）提供標準化的器件驅動模型，開發(fā)者無需獨立開發(fā)，通過配置即可完成驅動部署。

2）提供驅動模型抽象，屏蔽驅動與不同系統(tǒng)組件間的交互，使得驅動更具備通用型。

為了進一步簡化 OpenHarmony 系統(tǒng)驅動開發(fā)，OpenHarmony 系統(tǒng) HDF 驅動框架支持多種驅動加載方式：

支持驅動動態(tài)加載和靜態(tài)加載，解除驅動代碼和框架間的直接代碼依賴，使得驅動程序可以獨立編譯和部署；

支持按需動態(tài)加載方式，避免設備驅動全量加載，可有效降低系統(tǒng)資源的占用。

本文主要分析 OpenHarmony 系統(tǒng)驅動加載過程，在正式介紹之前，首先了解 OpenHarmony 系統(tǒng)驅動架構的組成、工作原理和機制，從而了解驅動加載的細節(jié)。

OpenHarmony系統(tǒng)

HDF驅動框架介紹

OpenHarmony 系統(tǒng) HDF 驅動框架主要由驅動基礎框架、驅動程序、驅動配置文件和驅動接口這四個部分組成。

1)HDF 驅動基礎框架提供統(tǒng)一的硬件資源管理，驅動加載管理以及設備節(jié)點管理等功能。驅動框架采用的是主從模式設計，由 Device Manager 和 Device Host 組成。

Device Manager 提供了統(tǒng)一的驅動管理，Device Manager 啟動時根據 Device Information 提供驅動設備信息加載相應的驅動 Device Host，并控制 Host 完成驅動的加載。

Device Host 提供驅動運行的環(huán)境，同時預置 Host Framework 與 Device Manager 進行協(xié)同，完成驅動加載和調用。根據業(yè)務的需求 Device Host 可以有多個實例。

說明Device Host 顧名思義就是驅動宿主，提供驅動運行的環(huán)境。 當驅動部署在用戶態(tài)時，Device Host 可以由獨立的進程進行承載， 當驅動在部署在內核態(tài)時，Device Host 僅表示邏輯隔離。 Device Host 的劃分原則： Device Host 屬于一類設備聚合，如 Camera，Audio，Display 等。 驅動程序是部署在一個 Device Host 還是部署在不同的 Device Host，主要考慮驅動程序之間是否存的業(yè)務耦合性，如果兩個驅動程序之間存在依賴，可以考慮將這部分驅動程序部署在統(tǒng)一 Host。

2)驅動程序實現驅動具體的功能，每個驅動由一個或者多個驅動程序組成，每個驅動程序都對應著一個 Driver Entry。Driver Entry 主要完成驅動的初始化和驅動接口綁定功能。

3)驅動配置文件.hcs主要由設備信息（Device Information）和設備資源（Device Resource）組成。Device Information 完成設備信息的配置。如配置接口發(fā)布策略，驅動加載的方式等。Device Resource 完成設備資源的配置。如 GPIO 管腳、寄存器等資源信息的配置。 4)驅動接口 HDI(Hardware Driver Interface )提供標準化的接口定義和實現，驅動框架提供 IO Service 和 IO Dispatcher 機制，使得不同部署形態(tài)下驅動接口趨于形式一致。驅動接口主要存在以下幾種實現：

當驅動以內核組件部署時，客戶端程序訪問驅動程序需要通過 system call 方式調用，驅動接口通過 IO Service 請求將消息通過 system call 方式調用到內核，并將消息分發(fā)到 IO Dispatcher 處理。

當驅動以用戶態(tài)服務形式部署時，客戶端進程訪問驅動進程需要通過 IPC 方式通信，IO Service 完成 IPC 通信的客戶端消息請求封裝，IO Dispatcher 完成驅動服務端消息請求封裝，客戶端消息通過 IPC 通信到達服務端并分發(fā)給 IO Dispatcher 處理。

當驅動部署在 RTOS（Real-Time Operating System）輕量化操作系統(tǒng)時，驅動接口和驅動程序之間采用的是 Function Call 方式調用，因此驅動接口僅提供定義，驅動接口實現由驅動程序提供。

Device Manager 提供了統(tǒng)一的驅動加載管理機制和驅動接口發(fā)布機制。

當 Device Host 環(huán)境加載完成時，Device Manager 根據 Device Information 信息，請求 Host 加載相應的驅動程序，Device Host 在收到請求時，進行以下操作：

1.根據請求加載設備信息，查找并加載指定路徑下驅動鏡像或從指定段地址(section)查找驅動程序入口。

2.查找驅動設備描述符，匹配對應的設備驅動。

3.當驅動匹配成功時，加載指定驅動程序鏡像。

4.Host Framework 在驅動程序鏡像加載成功后，調用驅動程序（Driver Entry）的綁定接口和初始化接口，實現與驅動程序的服務對象綁定，同時初始化設備驅動程序。

5.當 Device Information 配置中的服務策略要求對外暴露驅動接口時，驅動框架就將驅動程序的服務對象添加到對外發(fā)布的服務對象列表中，外部客戶端程序就可以通過此列表來查詢并訪問相應的服務接口。

對于驅動接口實現而言：

當驅動部署在內核態(tài)時，驅動接口部署在用戶態(tài)，驅動實現在內核態(tài)，驅動接口和驅動實現之間通過 syscall 調用方式實現調用交互。

當驅動部署在用戶態(tài)時，驅動接口和驅動實現分別部署在兩個進程中。驅動接口和驅動實現之間通過 IPC 調用方式實現調用交互。

為了使客戶端和服務端驅動調用方式基本一致，驅動框架提供 IO Service 和 IO Dispatcher 機制屏蔽了調用消息傳遞方式的差異。

驅動接口實現統(tǒng)一采用遠程調用的方式實現，客戶端驅動接口函數將請求序列化成內存數據，通過驅動框架提供的 IO Service 將消息發(fā)送到服務端處理，服務端在收到請求消息時通過 IO Dispatcher 機制將消息分發(fā)給消息處理函數處理，處理函數將反序列化內存數據解析成相應的請求。這樣的做到好處是，開發(fā)者只需重點關注接口的定義，無需過多的關注如何實現不同平臺上接口適配。

驅動加載過程分析

OpenHarmony 系統(tǒng)驅動根據驅動程序部署的不同方式，存在兩種驅動加載方式：

動態(tài)加載方式：采用傳統(tǒng)的 so（共享庫）加載方式，驅動程序通過指定 Symbol 方式找到驅動函數入口進行加載。

靜態(tài)加載方式：采用將驅動程序通過 Scatter 編譯到指定的 Section，再通過訪問指定 Section 對應的地址，找到驅動函數入口進行加載。

下面結合一個 Sample 示例代碼，講解驅動加載過程，重點分析靜態(tài)加載方式下內核態(tài)驅動加載過程。 實現驅動程序初始化接口在 HDF 驅動框架中，HdfDriverEntry 對象被用來描述一個驅動實現。

struct HdfDriverEntry { int32_t moduleVersion; const char *moduleName; int32_t (*Bind)(struct HdfDeviceObject *deviceObject); int32_t (*Init)(struct HdfDeviceObject *deviceObject); void (*Release)(struct HdfDeviceObject *deviceObject);};

編寫一個簡單的驅動，首先需要實現驅動程序 (Driver Entry)入口中的三個主要接口：

Bind 接口：實現驅動接口實例化綁定，如果需要發(fā)布驅動接口，會在驅動加載過程中被調用，實例化該接口的驅動服務并和 DeviceObject 綁定。

Init 接口：實現驅動的初始化，返回錯誤將中止驅動加載流程。

Release 接口：實現驅動的卸載，在該接口中釋放驅動實例的軟硬件資源。

int SampleDriverBind(struct HdfDeviceObject *deviceObject){ HDF_LOGE("SampleDriverBind enter!"); static struct IDeviceIoService testService = { .Dispatch = SampleServiceDispatch, .Open = NULL, .Release = NULL, }; deviceObject->service = &testService; return HDF_SUCCESS;} int SampleDriverInit(struct HdfDeviceObject *deviceObject){ HDF_LOGE("SampleDriverInit enter"); return HDF_SUCCESS;} void SampleDriverRelease(struct HdfDeviceObject *deviceObject){ HDF_LOGE("SampleDriverRelease enter"); return;} struct HdfDriverEntry g_sampleDriverEntry = { .moduleVersion = 1, .moduleName = "sample_driver", .Bind = SampleDriverBind, .Init = SampleDriverInit, .Release = SampleDriverRelease,}; HDF_INIT(g_sampleDriverEntry);

導出驅動程序入口符號實現驅動程序初始化后，需要將驅動程序入口通過驅動聲明宏導出，這樣驅動框架才能在啟動時識別到驅動程序的存在，驅動才能被加載：

#define HDF_INIT(module) HDF_DRIVER_INIT(module)

（左右滑動，查看更多）

這里將 HDF_INIT 宏展開：

#define HDF_SECTION __attribute__((section(".hdf.driver")))#define HDF_DRIVER_INIT(module) constsize_tUSED_ATTRmodule##HdfEntryHDF_SECTION=(size_t)(&(module))

（左右滑動，查看更多）

下面是其實現原理：

圖4 Driver Entry內存分布

可以看到 HDF_INIT 宏是定義了一個“驅動模塊名+HdfEntry”的符號放到".hdf.driver"所在 section，該符號指向的內存地址即為驅動程序入口結構體的地址。這個特殊的 section 將用于開機啟動時查找設備驅動。

添加設備配置

在設備對應的 device_info.hcs 添加 sample 驅動的配置：

sample_host :: host { hostName = "sample_host"; sample_device :: device { device0 :: deviceNode { policy = 2; priority = 100; preload = 1; permission = 0664; moduleName = "sample_driver"; serviceName = "sample_service"; } }}

在配置中定義的 device 將在加載過程中產生一個設備實例，通過 moduleName 字段指定設備對應的驅動名稱，從而將設備與驅動關聯起來，其中，設備與驅動可以是一對多的關系，即可以實現一個驅動支持多個同類型設備。 驅動啟動過程我們添加的驅動是如何被執(zhí)行的呢？簡單來說，在系統(tǒng)啟動時，驅動框架先啟動，通過解析配置文件獲取到設備列表，通過讀取".hdf.drivers"段讀取到驅動程序（Driver Entry）列表，然后遍歷設備列表與驅動程序列表進行匹配，并加載匹配成功的驅動。驅動框架有兩大核心管理者：

DeviceManager 負責設備的管理，包括設備加載、卸載和查詢等設備相關功能。

DeviceServiceManager 負責管理設備發(fā)布的接口服務，提供接口服務的發(fā)布、查詢等功能。

驅動加載主要由 DeviceManager 主導，首先 DeviceManager 要解析配置文件中的 Host 列表，根據 Host 列表中的信息來實例化對應的 Host 對象。Host 解析配置文件獲取到關聯的設備列表，遍歷設備列表去獲取與之匹配的驅動程序名稱，然后基于驅動程序名稱遍歷前面提到的.hdf.driver section 獲得驅動程序地址。

配置文本編譯后會變成二進制格式的配置文件，其中設備相關信息被存放在一個用“hdf_manager”標記的 device_info配置塊中，host 的內容以塊的形式在 device_info 塊中依次排列，host 塊中記錄了 host 名稱、啟動優(yōu)先級和設備列表信息。設備信息中的 moduleName 字段將用于和驅動程序入口中的 moduleName 進行匹配，從而為設備匹配到正確的驅動程序。 獲取驅動程序列表

HDF 驅動框架通過將驅動程序入口符號的地址集中存放到一個特殊的 section 來實現對驅動的索引，這個 section 的開頭和末尾插入了_hdf_drivers_start、_hdf_drivers_end 兩個特殊符號，用于標記這個 section 的范圍，兩個特殊符號之間的數據即為驅動實現指針。 驅動程序加載流程

Device Manager 遍歷設備列表，當查找到對應驅動實現時，為設備創(chuàng)建 Device 對象實例，如果設備配置中的 policy 字段為需要對外發(fā)布的驅動接口(SERVICE_POLICY_CAPACITY)，那么驅動的 Bind 接口將首先被調用，用于關聯設備和服務實例。然后驅動的 Init 接口將被調用，用于完成驅動的相關初始化工作。如果驅動被卸載或者因為硬件等原因 Init 接口返回失敗，Release 將被調用，用于釋放驅動申請的各類資源。

總結

本次和大家分享了 OpenHarmony 系統(tǒng)驅動的主要設計思想，重點分析了內核態(tài)驅動加載的過程，關于 OpenHarmony 系統(tǒng)驅動其他內容，后續(xù)會有更多技術文章向大家持續(xù)分享，敬請期待。

責任編輯：haq