HarmonyOS工具鏈 HarmonyOS驅(qū)動加載過程分析

　　HDF（Hardware Driver Foundation）驅(qū)動框架，為驅(qū)動開發(fā)者提供驅(qū)動框架能力，包括驅(qū)動加載、驅(qū)動服務(wù)管理和驅(qū)動消息機制。旨在構(gòu)建統(tǒng)一的驅(qū)動架構(gòu)平臺，為驅(qū)動開發(fā)者提供更精準、更高效的開發(fā)環(huán)境，力求做到一次開發(fā)，多系統(tǒng)部署。

　　一、HarmonyOS驅(qū)動概述

　　HarmonyOS驅(qū)動框架采用C語言面向?qū)ο缶幊棠Ｐ蜆?gòu)建，通過平臺解耦、內(nèi)核解耦，來達到兼容不同內(nèi)核，統(tǒng)一平臺底座的目的，從而幫助開發(fā)者實現(xiàn)驅(qū)動的“一次開發(fā)，多系統(tǒng)部署”。

　　為了達成這個目標， HarmonyOS驅(qū)動框架提供了：

　　1、操作系統(tǒng)適配層（OSAL，operating system abstraction layer）：提供內(nèi)核操作相關(guān)接口進行統(tǒng)一封裝，屏蔽不同系統(tǒng)操作接口。

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

　　3、驅(qū)動模型：面向器件驅(qū)動，提供常見的驅(qū)動抽象模型，主要達成兩個目的：

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

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

　　為了進一步簡化HarmonyOS驅(qū)動開發(fā)，HarmonyOS驅(qū)動框架支持多種驅(qū)動加載方式：

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

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

　　本文主要分析HarmonyOS驅(qū)動加載過程，在正式介紹之前，首先了解HarmonyOS驅(qū)動架構(gòu)的組成、工作原理和機制，從而了解驅(qū)動加載的細節(jié)。

　　官網(wǎng)相關(guān)介紹：https://device.harmonyos.com/cn/docs/develop/drive/oem_drive_hdfdev-0000001051715456

　　二、HarmonyOS驅(qū)動架構(gòu)介紹

　　2.1 HarmonyOS驅(qū)動架構(gòu)組成

　　圖1 HarmonyOS驅(qū)動架構(gòu)

　　HarmonyOS驅(qū)動架構(gòu)主要由HDF驅(qū)動框架、驅(qū)動程序、驅(qū)動配置文件和驅(qū)動接口四個部分組成。

　　1）HDF驅(qū)動框架提供統(tǒng)一的硬件資源管理，驅(qū)動加載管理以及設(shè)備節(jié)點管理等功能。

　　驅(qū)動框架采用的是主從模式設(shè)計，由Device Manager和Device Host組成。

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

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

　　說明：

　　Device Host顧名思義就是驅(qū)動宿主，提供驅(qū)動運行的環(huán)境。

　　當(dāng)驅(qū)動部署在用戶態(tài)時，Device Host可以由獨立的進程進行承載。

　　當(dāng)驅(qū)動在部署在內(nèi)核態(tài)時，Device Host僅表示邏輯隔離。

　　Device Host的劃分原則：Device Host屬于一類設(shè)備聚合，如Camera，Audio，Display等。

　　驅(qū)動程序是部署在一個Device Host還是部署在不同的Device Host，主要考慮驅(qū)動程序之間是否存的業(yè)務(wù)耦合性，如果兩個驅(qū)動程序之間存在依賴，可以考慮將這部分驅(qū)動程序部署在統(tǒng)一Host。

　　2）驅(qū)動程序?qū)崿F(xiàn)驅(qū)動的具體功能，每個驅(qū)動由一個或者多個驅(qū)動程序組成，每個驅(qū)動程序都對應(yīng)著一個Driver Entry。Driver Entry主要完成驅(qū)動的初始化和驅(qū)動接口綁定功能。

　　3）驅(qū)動配置文件.hcs主要由設(shè)備信息（Device Information）和設(shè)備資源（Device Resource）組成。

　　Device Information完成設(shè)備信息的配置，如配置接口發(fā)布策略，驅(qū)動加載的方式等。Device Resource 完成設(shè)備資源的配置，如GPIO管腳、寄存器等資源信息的配置。

　　4）驅(qū)動接口HDI（Hardware Driver interface ）提供標準化的接口定義和實現(xiàn)，驅(qū)動框架提供IO Service和IO Dispatcher機制，使得不同部署形態(tài)下驅(qū)動接口趨于形式一致。

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

　　2.2 HDF驅(qū)動框架工作原理

　　圖2 HDF驅(qū)動框架工作原理

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

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

　　1）根據(jù)請求加載設(shè)備信息，查找并加載指定路徑下驅(qū)動鏡像或從指定段地址（section）查找驅(qū)動程序入口；

　　2）查找驅(qū)動設(shè)備描述符，匹配對應(yīng)的設(shè)備驅(qū)動；

　　3）當(dāng)驅(qū)動匹配成功時，加載指定驅(qū)動程序鏡像；

　　4）Host Framework在驅(qū)動鏡像加載成功后，調(diào)用驅(qū)動程序（Driver Entry）的綁定接口和初始化接口，實現(xiàn)與驅(qū)動程序的服務(wù)對象綁定，同時初始化設(shè)備驅(qū)動程序；

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

　　2.3 驅(qū)動接口工作機制

　　圖3 驅(qū)動接口工作機制

　　驅(qū)動接口主要存在以下幾種實現(xiàn)：

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

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

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

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

　　三、驅(qū)動加載過程分析

　　HarmonyOS驅(qū)動根據(jù)部署的不同方式，存在兩種驅(qū)動加載方式：

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

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

　　下面結(jié)合一個Sample示例代碼，講解驅(qū)動加載過程，重點分析靜態(tài)加載方式下內(nèi)核態(tài)驅(qū)動加載過程。

　　3.1 實現(xiàn)驅(qū)動程序初始化接口

　　在HDF驅(qū)動框架中，HdfDriverEntry對象被用來描述一個驅(qū)動實現(xiàn)。

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

　　■ Bind接口：

　　實現(xiàn)驅(qū)動接口實例化綁定，如果需要發(fā)布驅(qū)動接口，會在驅(qū)動加載過程中被調(diào)用，實例化該接口的驅(qū)動服務(wù)并和DeviceObject綁定。

　　■ Init接口：

　　實現(xiàn)驅(qū)動的初始化，返回錯誤將中止驅(qū)動加載流程。

　　■ Release接口：

　　實現(xiàn)驅(qū)動的卸載，在該接口中釋放驅(qū)動實例的軟硬件資源。

　　3.2 導(dǎo)出驅(qū)動程序入口符號

　　實現(xiàn)驅(qū)動程序初始化后，需要將驅(qū)動程序入口通過驅(qū)動聲明宏導(dǎo)出，這樣驅(qū)動框架才能在啟動時識別到驅(qū)動程序的存在，驅(qū)動才能被加載：

　　下面是實現(xiàn)原理：

　　圖4 Driver Entry內(nèi)存分布

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

　　3.3 添加設(shè)備配置

　　在設(shè)備對應(yīng)的device_info.hcs添加sample驅(qū)動的配置：

　　在配置中定義的device將在加載過程中產(chǎn)生一個設(shè)備實例，通過moduleName字段指定設(shè)備對應(yīng)的驅(qū)動名稱，從而將設(shè)備與驅(qū)動關(guān)聯(lián)起來。其中，設(shè)備與驅(qū)動可以是一對多的關(guān)系，即可以實現(xiàn)一個驅(qū)動支持多個同類型設(shè)備。

　　3.4 驅(qū)動啟動過程

　　我們添加的驅(qū)動是如何被執(zhí)行的呢？簡單來說，在系統(tǒng)啟動時，驅(qū)動框架先啟動，通過解析配置文件獲取到設(shè)備列表，通過讀取“.hdf.driver”段讀取到驅(qū)動程序（Driver Entry）列表，然后遍歷設(shè)備列表與驅(qū)動程序列表進行匹配，并加載匹配成功的驅(qū)動。

　　驅(qū)動框架有兩大核心管理者：

　　● DeviceManager：負責(zé)設(shè)備的管理，包括設(shè)備加載、卸載和查詢等設(shè)備相關(guān)功能。

　　● DeviceServiceManager：負責(zé)管理設(shè)備發(fā)布的接口服務(wù)，提供接口服務(wù)的發(fā)布和查詢等功能。

　　驅(qū)動加載主要由DeviceManager主導(dǎo)，首先DeviceManager要解析配置文件中的Host列表，根據(jù)Host列表中的信息來實例化對應(yīng)的Host對象。Host解析配置文件獲取到關(guān)聯(lián)的設(shè)備列表，遍歷設(shè)備列表去獲取與之匹配的驅(qū)動程序名稱，然后基于驅(qū)動程序名稱遍歷前面提到的“.hdf.driver” section獲得驅(qū)動程序地址。

　　下面介紹具體過程。

　　3.4.1 獲取設(shè)備列表

　　圖5 設(shè)備列表結(jié)構(gòu)

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

　　3.4.2 獲取驅(qū)動程序列表

　　圖6 驅(qū)動程序（DriverEntry）內(nèi)存布局

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

　　3.4.3 驅(qū)動程序加載流程

　　圖7 HDF驅(qū)動加載流程

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

　　四、總結(jié)

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