在2月25日剛剛圓滿閉幕的首屆開放原子開源基金會OpenHarmony技術峰會（2023）生態與互聯分論壇上，潤和軟件旗下子公司江蘇潤開鴻數字科技有限公司（簡稱：潤開鴻）資深軟件開發工程師梁開祝發表了題為《OpenHarmony的驅動框架原理和實踐》的主題演講，從實踐角度重點講解了OpenHarmony驅動框架的具體實現細節和“一次開發，多系統部署”的驅動開發實踐，幫助OpenHarmony設備驅動開發者深入理解驅動框架工作流程和工作細節。

技術背景

OpenHarmony引入全新驅動開發理念和框架

OpenHarmony是一個面向萬物互聯/萬物智聯大場景的分布式操作系統，它面對的是硬件性能和功能需求千差萬別的設備，比如智能手環與手機之間的硬件差異。為了統一適配能力差別巨大的設備，OpenHarmony設計了一個多內核的架構，能力弱的設備選用簡單的內核（如LiteOS）、能力強的設備選用復雜的內核（如Linux），這意味著生態圈中的硬件產品在系統內核層面上就存在巨大的差異。然而這些產品很有可能會用到相近甚至相同的外圍硬件，比如，家里的智能門禁系統、智能電視、平板電腦、手機上所使用的攝像頭模組都可能是同一個型號或同系列的，而在設備端運行不同內核的操作系統，就需要為不同內核開發各自的驅動程序，這會造成驅動程序的復用性、可移植性、可維護性較差，不利于產品開發和維護，也不利于硬件生態圈的成長。

作為一個全新的操作系統，OpenHarmony必須要開發一套更優秀的驅動開發框架，幫助開發者、企業更便捷地開發和管理硬件設備的驅動程序，助力打造自己的硬件生態。OpenHarmony的驅動框架，采用C語言面向對象編程模型構建，通過平臺解耦、內核解耦，來達到兼容不同內核，統一平臺底座的目的，從而幫助開發者實現驅動一次開發，多系統部署的效果。

OpenHarmony的內核子系統（多內核）與驅動子系統（統一的驅動框架）是松耦合的關系，僅通過一個OSAL（Operating System Abstraction Layer，操作系統抽象層）進行交互。OSAL只為驅動框架提供內核部分關鍵能力的抽象接口，而隱藏了接口在不同內核中的實現細節。驅動框架通過OSAL來適配不同的內核，而具體的設備則完全基于驅動框架提供的能力來實現驅動程序并通過HDI（Hardware Driver Interface，硬件驅動接口）對上層提供驅動服務，設備驅動完全不需要知道（也不會知道）自己運行在什么樣的內核之上。

技術干貨

OpenHarmony中的驅動框架實現詳解

代碼結構

圖為OpenHarmony的驅動框架以及與驅動開發相關代碼部署。驅動框架主要在//drivers/hdf_core/目錄下實現。

lframework/目錄是C語言實現的驅動框架核心源代碼（包括驅動框架、配置管理、配置解析、驅動通用模型、硬件通用平臺能力接口等），

注意點：這里的部分代碼是內核態驅動框架與用戶態驅動框架共用的，需要大家在閱讀代碼時區分清楚；

l adapter/目錄下是驅動框架適配不同內核的適配代碼和編譯腳本，也包括用戶態驅動框架適配不同系統類型（輕量系統和標準系統）的適配代碼和編譯腳本。

l //drivers/peripheral/目錄下是部署在OpenHarmony用戶空間的各種外圍設備驅動相關的HDI、HAL、驅動模型及測試用例等的實現代碼和編譯配置。

l //drivers/interface/目錄下是用于管理各驅動模塊的HDI接口定義，這些接口定義使用IDL語言描述并以.idl文件形式保存。

l 其他與驅動開發相關的代碼目錄還包括//device/目錄和//vendor/目錄下的相關部分目錄，它們是具體的芯片方案、產品方案、產品定義、產品配置等相關信息和適配代碼的匯總，為設備驅動的實現提供一定的支持。

編譯與鏈接

驅動框架適配不同內核的編譯配置，在代碼結構的//drivers/hdf_core/adapter/目錄下，主要還是通過對應的BUILD.gn和Makefile文件將相關的源代碼進行串聯和依賴，以完成驅動框架整體的編譯與鏈接。

對于不同的內核，則在對應內核的編譯腳本中加入編譯驅動框架的入口和鏈接描述。

圖中代碼示例是在LiteOS_A內核的編譯腳本中include驅動框架的編譯入口，同時也在鏈接腳本中加入一個hdf.driver的只讀數據段，用以描述驅動框架專用的數據結構。

圖中代碼示例是在Linux內核的編譯腳本中，將驅動框架的關鍵代碼以patch的形式打入Linux源代碼中（實際仍是代碼目錄的軟鏈接形式加入Linux內核中），同時也在鏈接腳本vmlinux.lds.S中加入一個hdf.driver的只讀數據段，用以描述驅動框架專用的數據結構。

當編譯到OpenHarmony內核時，編譯工具鏈通過上述腳本的描述一并將驅動框架編譯成中間文件，然后鏈接和打包到內核鏡像中使用。

內核態驅動框架及用戶態驅動框架啟動流程

內核態驅動框架的啟動流程

如圖所示，部署在內核態的驅動框架作為一個相對獨立的部分，要么因為內核（LiteOS_A內核）的其他模塊的直接調用而啟動，要么作為內核（Linux內核）的一個模塊（module）而自動加載和啟動。在進入驅動框架的啟動入口之后，驅動框架就會進入一個與內核無關的工作流程中（與內核相關部分會通過OSAL接口對接到內核提供的功能）。

用戶態驅動框架的啟動流程

如圖所示，部署在用戶態的驅動框架則分為若干個獨立的服務進程，在系統啟動到用戶態階段時，由Init進程根據啟動配置文件的描述逐一拉起，各進程之間通過IPC進行交互并逐步建立起各自的數據結構關系。

以上兩張示意圖均為以功能模塊劃分的啟動流程概略圖，梁開祝老師在閱讀理解OpenHarmony驅動框架的代碼時，以API為粒度整理了一份詳細的啟動流程圖，以及在驅動框架啟動過程中一步步建立起來的數據結構關系圖，感興趣的讀者可到資源倉庫下載、閱讀：

倉庫地址：

https://gitee.com/liangkzgitee/ohos_study_note

用戶態與內核態的交互

內核態的驅動框架與用戶態的驅動框架是各自獨立的兩部分，內核態驅動框架直接管理具體硬件設備的驅動，并以服務的形式向用戶態提供服務接口，而用戶態驅動框架則通過HDI接口使用內核態驅動框架提供的驅動服務。

HDI接口使用IO Service和IO Dispatcher機制為驅動框架提供進行統一的交互接口，其實現主要有兩種形式：

l 當驅動以內核態組件形式部署時，客戶端程序需要通過系統調用（system call）方式訪問驅動程序。驅動接口通過IO Service請求將消息通過系統調用陷入內核，并將消息分發到IO Dispatcher進行處理。

l 當驅動以用戶態服務形式部署時，客戶端進程需要通過IPC方式訪問驅動服務進程，IO Service完成IPC 通信的客戶端消息請求封裝，IO Dispatcher完成驅動服務端消息請求封裝，客戶端消息通過IPC送達服務端再分發給IO Dispatcher處理。

注意點：該交互過程涉及比較復雜的數據處理流程，需要結合代碼進行深入理解。

通用的驅動示例程序

以一個通用的驅動示例程序來簡單驗證基于OpenHarmony驅動框架的設備驅動開發基本要點。

本驅動示例程序，包含了驅動框架的一些基本要素，如上層的應用程序、內核的驅動程序、硬件的驅動配置信息、適配不同內核和不同類型系統的編譯腳本等。小伙伴們可以跟著里面的README文檔的操作說明，從簡單到復雜一步步去驗證前文提到的驅動框架知識要點，也可以非常方便地將這個示例程序移植到不同的開發板上進行驗證，以此體驗OpenHarmony驅動框架“一次開發，多系統部署”的好處。

“以技術賦能開源共建，持續發揮生態引領作用”。潤和軟件將深入貫徹“2+N”行業戰略（深耕金融、能源“2”大行業，廣泛賦能智慧城市、醫療、教育、工業等“N”個行業），圍繞行業場景落地不斷夯實軟硬件底座，推動應用創新，助力體驗提升；吸引更多企業及個人開發者融入生態、參與共建，持續為OpenHarmony繁榮發展貢獻力量。