概述
HDF(Hardware Driver Foundation)驅動框架,為驅動開發者提供驅動框架能力,包括驅動加載、驅動服務管理、驅動消息機制和配置管理。并以組件化驅動模型作為核心設計思路,讓驅動開發和部署更加規范,旨在構建統一的驅動架構平臺,為驅動開發者提供更精準、更高效的驅動管理的開發環境,力求做到一次開發,多系統部署。
驅動加載
HDF驅動框架提供把和配置的設備列表匹配成功的驅動程序加載起來的功能。
驅動服務管理
HDF框架可以集中管理驅動服務,開發者可直接通過HDF框架對外提供的能力接口獲取驅動相關的服務。
驅動消息機制
HDF框架提供統一的驅動消息機制,支持用戶態應用向內核態驅動發送消息,也支持內核態驅動向用戶態應用發送消息。
配置管理
HCS(HDF Configuration Source)是HDF驅動框架的配置描述源碼,內容以Key-Value為主要形式。它實現了配置代碼與驅動代碼解耦,便于開發者進行配置管理。
驅動模型
HDF框架將一類設備驅動放在同一個Host(設備容器)里面,用于管理一組設備的啟動加載等過程。在劃分Host時,驅動程序是部署在一個Host還是部署在不同的Host,主要考慮驅動程序之間是否存在耦合性,如果兩個驅動程序之間存在依賴,可以考慮將這部分驅動程序部署在一個Host里面,否則部署到獨立的Host中是更好的選擇。Device對應一個真實的物理設備。DeviceNode是設備的一個部件,Device至少有一個DeviceNode。每個DeviceNode可以發布一個設備服務。驅動即驅動程序,每個DevicdNode唯一對應一個驅動,實現和硬件的功能交互。HDF驅動模型如下圖所示:
圖1?HDF驅動模型
?點擊領取→純血鴻蒙Next全套最新學習資料(安全鏈接,放心點擊)希望這一份鴻蒙學習資料能夠給大家帶來幫助,有需要的小伙伴自行領取~
功能描述
驅動加載
HDF驅動框架提供把和配置的設備列表匹配成功的驅動程序加載起來的功能,支持按需加載和按序加載兩種策略,具體設備的加載策略由配置文件中的preload字段來控制,配置值參考如下:
typedef enum {DEVICE_PRELOAD_ENABLE = 0,DEVICE_PRELOAD_ENABLE_STEP2 = 1,DEVICE_PRELOAD_DISABLE = 2,DEVICE_PRELOAD_INVALID
} DevicePreload;
按需加載
- preload字段配置為0(DEVICE_PRELOAD_ENABLE),則系統啟動過程中默認加載。
- preload字段配置為1(DEVICE_PRELOAD_ENABLE_STEP2),當系統支持快速啟動的時候,則在系統完成之后再加載這一類驅動,否則和DEVICE_PRELOAD_ENABLE含義相同。
- preload字段配置為2(DEVICE_PRELOAD_DISABLE),則系統啟動過程中默認不加載,支持后續動態加載,當用戶態獲取驅動服務消息機制時,如果驅動服務不存在,HDF框架會嘗試動態加載該驅動。
按序加載(默認加載策略)
配置文件中的priority(取值范圍為整數0到200)是用來表示host(驅動容器)和驅動的優先級的。不同的host內的驅動,host的priority值越小,驅動加載優先級越高;同一個host內驅動的priority值越小,加載優先級越高。
異常恢復(用戶態驅動)
當驅動服務異常退出時,恢復策略如下:
- preload字段配置為0(DEVICE_PRELOAD_ENABLE)或1(DEVICE_PRELOAD_ENABLE_STEP2)的驅動服務,由啟動模塊拉起host并重新加載服務。
- preload字段配置為2(DEVICE_PRELOAD_DISABLE)的驅動服務,需業務模塊注冊HDF的服務狀態監聽器,當收到服務退出消息時,業務模塊調用LoadDevice重新加載服務。
驅動服務管理
驅動服務是HDF驅動設備對外提供能力的對象,由HDF框架統一管理。驅動服務管理主要包含驅動服務的發布和獲取。HDF框架定義了驅動對外發布服務的策略,由配置文件中的policy字段來控制,policy字段的取值范圍以及含義如下:
typedef enum {/* 驅動不提供服務 */SERVICE_POLICY_NONE = 0,/* 驅動對內核態發布服務 */SERVICE_POLICY_PUBLIC = 1,/* 驅動對內核態和用戶態都發布服務 */SERVICE_POLICY_CAPACITY = 2,/* 驅動服務不對外發布服務,但可以被訂閱 */SERVICE_POLICY_FRIENDLY = 3,/* 驅動私有服務不對外發布服務,也不能被訂閱 */SERVICE_POLICY_PRIVATE = 4,/* 錯誤的服務策略 */SERVICE_POLICY_INVALID
} ServicePolicy;
使用場景
當驅動需要以接口的形式對外提供能力時,可以使用HDF框架的驅動服務管理能力。
接口說明
針對驅動服務管理功能,HDF框架開放了以下接口供開發者調用,如下表所示:
表1?服務管理接口
方法 | 描述 |
---|---|
int32_t (*Bind)(struct HdfDeviceObject *deviceObject) | 需要驅動開發者實現Bind函數,將自己的服務接口綁定到HDF框架中。 |
const struct HdfObject *DevSvcManagerClntGetService(const char *svcName) | 獲取驅動的服務。 |
int HdfDeviceSubscribeService( struct HdfDeviceObject *deviceObject, const char *serviceName, struct SubscriberCallback callback) | 訂閱驅動的服務。 |
驅動消息機制管理
使用場景
當用戶態應用和內核態驅動需要交互時,可以使用HDF框架的消息機制來實現。
接口說明
消息機制的功能主要有以下兩種:
- 用戶態應用發送消息到驅動。
- 用戶態應用接收驅動主動上報事件。
表2?消息機制接口
方法 | 描述 |
---|---|
struct HdfIoService *HdfIoServiceBind(const char *serviceName); | 用戶態獲取驅動的服務,獲取該服務之后通過服務中的Dispatch方法向驅動發送消息。 |
void HdfIoServiceRecycle(struct HdfIoService *service); | 釋放驅動服務。 |
int HdfDeviceRegisterEventListener(struct HdfIoService *target, struct HdfDevEventlistener *listener); | 用戶態程序注冊接收驅動上報事件的操作方法。 |
int32_t HdfDeviceSendEvent(const struct HdfDeviceObject *deviceObject, uint32_t id, const struct HdfSBuf *data) | 驅動主動上報事件接口。 |
配置管理
配置概述
HCS(HDF Configuration Source)是HDF驅動框架的配置描述源碼,內容以Key-Value為主要形式。它實現了配置代碼與驅動代碼解耦,便于開發者進行配置管理。HC-GEN(HDF Configuration Generator)是HCS配置轉換工具,可以將HDF配置文件轉換為軟件可讀取的文件格式:
- 在弱性能環境中,轉換為配置樹源碼或配置樹宏定義,驅動可直接調用C代碼或宏式APIs獲取配置。
- 在高性能環境中,轉換為HCB(HDF Configuration Binary)二進制文件,驅動可使用HDF框架提供的配置解析接口獲取配置。
以下是使用HCB模式的典型應用場景:
圖2?配置使用流程圖
HCS經過HC-GEN編譯生成HCB文件,HDF驅動框架中的HCS Parser模塊會從HCB文件中重建配置樹,HDF驅動模塊使用HCS Parser提供的配置讀取接口獲取配置內容。
配置語法
HCS的語法介紹如下:
關鍵字
HCS配置語法保留了以下關鍵字。
表3?HCS配置語法保留關鍵字
關鍵字 | 用途 | 說明 |
---|---|---|
root | 配置根節點 | - |
include | 引用其他HCS配置文件 | - |
delete | 刪除節點或屬性 | 只能用于操作include導入的配置樹 |
template | 定義模板節點 | - |
match_attr | 用于標記節點的匹配查找屬性 | 解析配置時可以使用該屬性的值查找到對應節點 |
基本結構
HCS主要分為屬性(Attribute)和節點(Node)兩種結構。
屬性
屬性即最小的配置單元,是一個獨立的配置項。語法如下:
attribute_name = value;
- attribute_name是字母、數字、下劃線的組合且必須以字母或下劃線開頭,字母區分大小寫。
- value的可用格式如下:
- 數字常量,支持二進制、八進制、十進制、十六進制數,具體數據類型章節。
- 字符串,內容使用雙引號("")引用。
- 節點引用。
- attribute必須以分號(;)結束且必須屬于一個node。
節點
節點是一組屬性的集合,語法如下:
node_name {module = "sample";...}
- node_name是字母、數字、下劃線的組合且必須以字母或下劃線開頭,字母區分大小寫。
- 大括號后無需添加結束符“;”。
- root為保留關鍵字,用于聲明配置表的根節點。每個配置表必須以root節點開始。
- root節點中必須包含module屬性,其值應該為一個字符串,用于表征該配置所屬模塊。
- 節點中可以增加match_attr屬性,其值為一個全局唯一的字符串。當驅動程序在解析配置時可以以該屬性的值為參數調用查找接口查找到包含該屬性的節點。
數據類型
在屬性定義中使用自動數據類型,不顯式指定類型,屬性支持的數據類型如下:
整型
整型長度自動推斷,根據實際數據長度給與最小空間占用的類型。
- 二進制,0b前綴,示例:0b1010。
- 八進制,0前綴,示例:0664。
- 十進制 ,無前綴,且支持有符號與無符號,示例:1024,+1024均合法。驅動程序在讀取負值時注意使用有符號數讀取接口。
- 十六進制,0x前綴,示例:0xff00、0xFF。
字符串
字符串使用雙引號("")表示。
數組
數組元素支持整型、字符串,不支持混合類型。整型數組中uint32_t uint64_t混用會向上轉型為uint64_t數組。整型數組與字符串數組示例如下:
attr_foo = [0x01, 0x02, 0x03, 0x04];
attr_bar = ["hello", "world"];
bool類型
bool類型中true表示真,false表示假。
預處理
include
用于導入其他HCS文件。語法示例如下:
#include "foo.hcs"
#include "../bar.hcs"
- 文件名必須使用雙引號(""),不在同一目錄使用相對路徑引用。被include文件也必須是合法的HCS文件。
- 多個include,如果存在相同的節點,后者覆蓋前者,其余的節點依次展開。
注釋
支持兩種注釋風格。
-
單行注釋。
// comment
-
多行注釋。
/* comment */
說明:?多行注釋不支持嵌套。
引用修改
引用修改的作用是在當前節點中修改另外任意一個節點的內容,語法為:
node :& source_node
上述語句表示node中的內容是對source_node節點內容的修改。示例如下:
root {module = "sample";foo {foo_ :& root.bar{attr = "foo";}foo1 :& foo2 {attr = 0x2;}foo2 {attr = 0x1;}}bar {attr = "bar";}
}
最終生成配置樹為:
root {module = "sample";foo {foo2 {attr = 0x2;}}bar {attr = "foo";}
}
在以上示例中,可以看到foo.foo_節點通過引用將bar.attr屬性的值修改為了"foo",foo.foo1節點通過引用將foo.foo2.attr屬性的值修改為了0x2。foo.foo_以及foo.foo1節點表示對目標節點內容的修改,其自身并不會存在最終生成的配置樹中。
- 引用同級node,可以直接使用node名稱,否則被引用的節點必須使用絕對路徑,節點間使用“.”分隔,root表示根節點,格式為root開始的節點路徑序列,例如root.foo.bar即為一個合法的絕對路徑。
- 如果出現修改沖突(即多處修改同一個屬性),編譯器將提示warning,因為這種情況下只會生效某一個修改而導致最終結果不確定。
節點復制
節點復制可以實現在節點定義時從另一個節點先復制內容,用于定義內容相似的節點。語法為:
node : source_node
上述語句表示在定義"node"節點時將另一個節點"source_node"的屬性復制過來。示例如下:
root {module = "sample";foo {attr_0 = 0x0;}bar:foo {attr_1 = 0x1;}
}
上述代碼的最終生成配置樹為:
root {module = "sample";foo {attr_0 = 0x0;}bar {attr_1 = 0x1;attr_0 = 0x0;}
}
在上述示例中,編譯后bar節點既包含attr_0屬性又包含attr_1屬性,在bar中對attr_0的修改不會影響到foo。
當foo和bar在同級node中時可不指定foo的路徑,否則需要使用絕對路徑引用,絕對路徑的介紹請參考引用修改。
刪除
要對include導入的base配置樹中不需要的節點或屬性進行刪除,可以使用delete關鍵字。下面的舉例中sample1.hcs通過include導入了sample2.hcs中的配置內容,并使用delete刪除了sample2.hcs中的attribute2屬性和foo_2節點,示例如下:
// sample2.hcs
root {attr_1 = 0x1;attr_2 = 0x2;foo_2 {t = 0x1;}
}// sample1.hcs
#include "sample2.hcs"
root {attr_2 = delete;foo_2 : delete {}
}
上述代碼在生成過程中將會刪除root.foo_2節點與attr_2,最終生成配置樹為:
root {attr_1 = 0x1;
}
說明:?在同一個HCS文件中不允許使用delete,建議直接刪除不需要的屬性。
屬性引用
為了在解析配置時快速定位到關聯的節點,可以把節點作為屬性的右值,通過讀取屬性查找到對應節點。語法為:
attribute = &node;
上述語句表示attribute的值是一個節點node的引用,在解析時可以用這個attribute快速定位到node,便于關聯和查詢其他node。示例如下:
node1 {attributes;
}
node2 {attr_1 = &root.node1;
}
或
node2 {node1 {attributes;}attr_1 = &node1;
}
模板
模板的用途在于生成嚴格一致的node結構,以便對同類型node進行遍歷和管理。使用template關鍵字定義模板node,子node通過雙冒號“::”聲明繼承關系。子節點可以改寫或新增但不能刪除template中的屬性,子節點中沒有定義的屬性將使用template中的定義作為默認值。示例如下:
root {module = "sample";template foo {attr_1 = 0x1;attr_2 = 0x2;}bar :: foo {}bar_1 :: foo {attr_1 = 0x2;}
}
? 生成配置樹如下:
root {module = "sample";bar {attr_1 = 0x1;attr_2 = 0x2;}bar_1 {attr_1 = 0x2;attr_2 = 0x2;}
}
在上述示例中,bar和bar_1節點繼承了foo節點,生成配置樹節點結構與foo保持了完全一致,只是屬性的值不同。
配置生成
? hc-gen是配置生成的工具,可以對HCS配置語法進行檢查并把HCS源文件轉化成HCB二進制文件。
hc-gen介紹
? hc-gen參數說明:
Usage: hc-gen [Options] [File]
options:-o <file> output file name, default same as input-a hcb align with four bytes-b output binary output, default enable-t output config in C language source file style-m output config in macro source file style-i output binary hex dump in C language source file style-p <prefix> prefix of generated symbol name-d decompile hcb to hcs-V show verbose info-v show version-h show this help message
生成.c/.h配置文件方法:
hc-gen -o [OutputCFileName] -t [SourceHcsFileName]
生成HCB配置文件方法:
hc-gen -o [OutputHcbFileName] -b [SourceHcsFileName]
生成宏定義配置文件方法:
hc-gen -o [OutputMacroFileName] -m [SourceHcsFileName]
反編譯HCB文件為HCS方法:
hc-gen -o [OutputHcsFileName] -d [SourceHcbFileName]
最后
有很多小伙伴不知道學習哪些鴻蒙開發技術?不知道需要重點掌握哪些鴻蒙應用開發知識點?但是又不知道從哪里下手,而且學習時頻繁踩坑,最終浪費大量時間。所以本人整理了一些比較合適的鴻蒙(HarmonyOS NEXT)學習路徑和一些資料的整理供小伙伴學習
點擊領取→純血鴻蒙Next全套最新學習資料(安全鏈接,放心點擊)
希望這一份鴻蒙學習資料能夠給大家帶來幫助,有需要的小伙伴自行領取,限時開源,先到先得~無套路領取!!
一、鴻蒙(HarmonyOS NEXT)最新學習路線
?
有了路線圖,怎么能沒有學習資料呢,小編也準備了一份聯合鴻蒙官方發布筆記整理收納的一套系統性的鴻蒙(OpenHarmony )學習手冊(共計1236頁)與鴻蒙(OpenHarmony )開發入門教學視頻,內容包含:(ArkTS、ArkUI開發組件、Stage模型、多端部署、分布式應用開發、音頻、視頻、WebGL、OpenHarmony多媒體技術、Napi組件、OpenHarmony內核、Harmony南向開發、鴻蒙項目實戰等等)鴻蒙(HarmonyOS NEXT)…等技術知識點。
獲取以上完整版高清學習路線,請點擊→純血版全套鴻蒙HarmonyOS學習資料
二、HarmonyOS?Next 最新全套視頻教程
?
三、《鴻蒙 (OpenHarmony)開發基礎到實戰手冊》
OpenHarmony北向、南向開發環境搭建
?
《鴻蒙開發基礎》
- ArkTS語言
- 安裝DevEco Studio
- 運用你的第一個ArkTS應用
- ArkUI聲明式UI開發
- .……
?
《鴻蒙開發進階》
- Stage模型入門
- 網絡管理
- 數據管理
- 電話服務
- 分布式應用開發
- 通知與窗口管理
- 多媒體技術
- 安全技能
- 任務管理
- WebGL
- 國際化開發
- 應用測試
- DFX面向未來設計
- 鴻蒙系統移植和裁剪定制
- ……
?
《鴻蒙進階實戰》
- ArkTS實踐
- UIAbility應用
- 網絡案例
- ……
?
四、大廠面試必問面試題
?
五、鴻蒙南向開發技術
?
六、鴻蒙APP開發必備
?
七、鴻蒙生態應用開發白皮書V2.0PDF
?
完整鴻蒙HarmonyOS學習資料,請點擊→純血版全套鴻蒙HarmonyOS學習資料
總結
總的來說,華為鴻蒙不再兼容安卓,對中年程序員來說是一個挑戰,也是一個機會。只有積極應對變化,不斷學習和提升自己,他們才能在這個變革的時代中立于不敗之地。?
? ? ? ? ? ? ? ? ? ? ? ??