|
品讀鴻蒙HDF架構(gòu)(一),
1.鋪墊一下 鴻蒙系統(tǒng)終于公開源代碼了,正可謂“千呼萬喚始出來”。筆者也手癢下載了一套代碼,并研讀了一二。這里就先編寫一篇關(guān)于HDF的文檔。
其實,不同讀碼人都會有各自讀代碼的習(xí)慣和切入點,我之所以從HDF入手,完全是出于偶然。因為在一開始讀官方文檔時,看到說一部機器可以操作另一部機器的設(shè)備,為此,設(shè)備需要有一個重要的PublishService()函數(shù)。這種跨設(shè)備操作的能力也是鴻蒙的一大特色,應(yīng)該比較有趣,于是就以這個PublishService()為切入點,開始研讀代碼,慢慢就涉及了HDF的更多知識,現(xiàn)在是時候整理出來了。
所謂HDF,應(yīng)該是Harmony Driver Fundation的縮寫,說到底是鴻蒙形成的一套管理設(shè)備驅(qū)動的框架模型,也被稱為“驅(qū)動子系統(tǒng)”。在官網(wǎng)的文檔里介紹說這個驅(qū)動子系統(tǒng)具有以下重要能力:
- 彈性化的框架能力
- 規(guī)范化的驅(qū)動接口
- 組件化的驅(qū)動模型
- 歸一化的配置界面
讀完這四句話,不免讓人覺得好像明白了什么,又好像什么都沒明白。好吧,我還是按自己的習(xí)慣直接讀代碼吧。
為了便于理解代碼,我習(xí)慣于把軟件圖形化。為此,我介紹一點我的圖形表達方法。在我讀Java代碼時,如果要表達A類對象的某個成員引用了另一個B類對象,我常常會這樣繪制: 但是HDF的代碼是用C寫的,所以對應(yīng)的圖形表達法也要有所變化。我們要區(qū)分一下:
1)A結(jié)構(gòu)以某成員組合了另一個B結(jié)構(gòu);
2)A結(jié)構(gòu)某成員是個指向B的指針;
這兩種情況可以分別表示為: 另外,有時候HDF會使用C語言的一些技巧進行鏈表表達或基類轉(zhuǎn)換,那么上面的圖形畫出來就會很累贅,針對這種情況,我有時候會這樣表達(以DevmgrService結(jié)構(gòu)為例): 可以看出,DevmgrService繼承于IDevmgrService,而IDevmgrService又在起始處組合了一個HdfDeviceObject(有時候也可以說是繼承于HdfDeviceObject)。也就是說:
1)DevmgrService的起始地址;
2)DevmgrService內(nèi)部IDevmgrService部分的起始地址;
3)IDevmgrService內(nèi)部HdfDeviceObject部分的起始地址;
這3個起始地址其實是同一處。用這種表達法,我們就不必畫出3個分離的框圖了。 好了,鋪墊部分就先寫這么多,下面我們來看HDF的實際內(nèi)容。
2.DevmgrService和Dev Host 我們以hi3516 dv300為例,其系統(tǒng)一啟動,會運行到SystemInit(),其中會調(diào)用DeviceManagerStart()啟動與HDF相關(guān)的部分:
【vendor/hisi/hi35xx/hi3516dv300/module_init/src/System_init.c】
- void SystemInit(void)
- {
- . . . . . .
- #ifdef LOSCFG_DRIVERS_HDF
- if (DeviceManagerStart()) {
- PRINT_WARN(“No drivers need load by hdf manager!“);
- }
- #endif
- . . . . . .
- }
復(fù)制代碼
2.1 啟動DeviceManager 【drivers/hdf/lite/manager/src/Devmgr_service_start.c】
- int DeviceManagerStart()
- {
- struct IDevmgrService *instance = DevmgrServiceGetInstance();
-
- if (instance == NULL || instance->StartService == NULL) {
- HDF_LOGE(“Device manager start faiLED, service instance is null!“);
- return HDF_FAILURE;
- }
- struct HdfIoService *ioService = HdfIoServiceBind(DEV_MGR_NODE, DEV_MGR_NODE_PERM);
- if (ioService != NULL) {
- static struct HdfIoDispatcher dispatcher = {
- .Dispatch = DeviceManagerDispatch,
- };
- ioService->dispatcher = &dispatcher;
- ioService->target = (struct HdfObject *)&instance->object;
- }
- return instance->StartService(instance);
- }
復(fù)制代碼 簡單地說,要啟動DeviceManager服務(wù),就得先獲取一個DevmgrService實例,然后調(diào)用它的StartService(),又因為DevmgrService繼承于IDevmgrService,所以可以強制轉(zhuǎn)換成IDevmgrService*。
2.1.1 獲取DevmgrService單例 獲取實例時,其實用到了HDF機制提供的一個對象管理器,相關(guān)代碼如下:
【drivers/hdf/frameworks/core/manager/src/Devmgr_service.c】
- struct IDevmgrService *DevmgrServiceGetInstance()
- {
- static struct IDevmgrService *instance = NULL; // 注意是static的,表示是個靜態(tài)單例
- if (instance == NULL) {
- instance = (struct IDevmgrService *)
- HdfObjectManagerGetObject(HDF_OBJECT_ID_DEVMGR_SERVICE);
- }
- return instance;
- }
復(fù)制代碼 以后我們會看到,這個HdfObjectManagerGetObject()會在多個地方調(diào)用,以便獲取不同的HDF對象。說起來也簡單,HDF機制里有一張表,記錄著該如何創(chuàng)建、釋放一些重要的HDF對象,該表格為g_liteObjectCreators:
【drivers/hdf/lite/manager/src/Devlite_object_config.c】 static const struct HdfObjectCreator g_liteObjectCreators[] 基于讀到的代碼,我們可以畫出這個表格:
20.png (36.23 KB, 下載次數(shù): 0)
下載附件 保存到相冊
22 分鐘前 上傳
概念還是比較簡單的,如果系統(tǒng)中的DevmgrService單例對象已經(jīng)存在,就使用之。否則就利用HDF對象管理器創(chuàng)建一個DevmgrService對象。對于HDF對象管理器而言,不同類型的HDF對象,需要用到不同的創(chuàng)建函數(shù),所以要查一下上表。比如DevmgrService對應(yīng)的創(chuàng)建函數(shù)就是DevmgrServiceCreate(),該函數(shù)代碼如下:
【drivers/hdf/frameworks/core/manager/src/Devmgr_service.c】
- struct HdfObject *DevmgrServiceCreate()
- {
- static bool isDevMgrServiceInit = false;
- static struct DevmgrService devmgrServiceInstance;
- if (!isDevMgrServiceInit) {
- if (!DevmgrServiceConstruct(&devmgrServiceInstance)) {
- return NULL;
- }
- isDevMgrServiceInit = true;
- }
- return (struct HdfObject *)&devmgrServiceInstance; // ???HdfObject,有小問題!
- }
復(fù)制代碼 在“創(chuàng)建”時,如果發(fā)現(xiàn)是首次創(chuàng)建,則調(diào)用一個類似構(gòu)造函數(shù)的DevmgrServiceConstruct()函數(shù),來初始化對象里的函數(shù)表。這種做法是用C語言實現(xiàn)面向?qū)ο蟾拍畹某S米龇ā2贿^,此處的代碼有一個小bug,即最后那個強制轉(zhuǎn)換,從目前看到的代碼來說,DevmgrService間接繼承于HdfDeviceObject,而HdfDeviceObject并不繼承于HdfObject,所以是不應(yīng)該這樣強制轉(zhuǎn)換的,除非HdfDeviceObject的第一個成員從“IDeviceIoService*”改為“IDeviceIoService”,我估計最早的代碼就是IDeviceIoService,后來因為某些原因,變成了指針形式,至于以后具體該怎么修正,這個就讓鴻蒙的工程師去費腦筋吧。DevmgrService的構(gòu)造函數(shù)如下:
【drivers/hdf/frameworks/core/manager/src/Devmgr_service.c】
- static bool DevmgrServiceConstruct(struct DevmgrService *inst)
- {
- if (OsalMutexInit(&inst->devMgrMutex) != HDF_SUCCESS) {
- HDF_LOGE(“%s mutex init failed“, __func__);
- return false;
- }
- struct IDevmgrService *devMgrSvcIf = (struct IDevmgrService *)inst;
- if (devMgrSvcIf != NULL) {
- devMgrSvcIf->AttachDevice = DevmgrServiceAttachDevice;
- devMgrSvcIf->AttachDeviceHost = DevmgrServiceAttachDeviceHost;
- devMgrSvcIf->StartService = DevmgrServiceStartService;
- devMgrSvcIf->AcquireWakeLock = DevmgrServiceAcquireWakeLock;
- devMgrSvcIf->ReleaseWakeLock = DevmgrServiceReleaseWakeLock;
- HdfSListInit(&inst->hosts);
- }
- return true;
- }
復(fù)制代碼
2.1.2 HdfIoServiceBind() 啟動DeviceManager時,第二個重要的動作是調(diào)用HdfIoServiceBind(): struct HdfIoService *ioService = HdfIoServiceBind(DEV_MGR_NODE, DEV_MGR_NODE_PERM); 這一步在做什么呢?我們可以這樣理解,DevmgrService作為一個核心的系統(tǒng)服務(wù),我們希望能像訪問虛文件系統(tǒng)的文件那樣打開它,并進一步向它傳遞諸如AttachDevice、StartServie......這樣的語義。這些語義最終會執(zhí)行到上面列舉的DevmgrServiceAttachDevice、DevmgrServiceStartService等函數(shù)。 我們不必列舉太多代碼,下面是我繪制的一張關(guān)于DeviceManagerStart()的調(diào)用關(guān)系示意圖,可供參考: 圖中已經(jīng)明確注明,DevmgrService在虛文件系統(tǒng)里對應(yīng)的路徑應(yīng)該是“/dev/dev_mgr”,而上面調(diào)用HdfIoServiceBind()后,實際上建立了一個文件系統(tǒng)的inode節(jié)點,示意圖如下: HdfVNodeAdapter的target在最后賦值為(struct HdfObject*)&instance->object,說到底其實就是指向了DevmgrService。
2.1.3 執(zhí)行DevmgrService的StartService 接下來是啟動DeviceManager的第三步,調(diào)用instance->StartService(),這一步其實是在調(diào)用DevmgreviceStartService()函數(shù)。
【drivers/hdf/frameworks/core/manager/src/Devmgr_service.c】
- int DevmgrServiceStartService(struct IDevmgrService *inst)
- {
- struct DevmgrService *dmService = (struct DevmgrService *)inst;
- if (dmService == NULL) {
- HDF_LOGE(“Start device manager service failed, dmService is null“);
- return HDF_FAILURE;
- }
- return DevmgrServiceStartDeviceHosts(dmService);
- }
復(fù)制代碼 主要就是在調(diào)用一個DevmgrServiceStartDeviceHosts()函數(shù)。這個函數(shù)應(yīng)該算是個重量級函數(shù),它會負(fù)責(zé)建立起DevmgrService內(nèi)部主要的數(shù)據(jù)結(jié)構(gòu)。我們先繪制一下該函數(shù)第一層次的調(diào)用關(guān)系,如下圖: 在進一步深入代碼細(xì)節(jié)之前,我們最好先大概說明一下。在鴻蒙HDF架構(gòu)里,有一個“設(shè)備Host”的概念,根據(jù)官方的文檔,我們大概可以知道,一個Host用于整合若干業(yè)務(wù)相近的設(shè)備,這個原則被稱為相似相容原則。為了實現(xiàn)這個原則,HDF構(gòu)造了一系列數(shù)據(jù)結(jié)構(gòu),我們列舉一下: 1)HdfHostInfo
2)DevHostServiceClnt
3)DevHostService
4)HdfDevice
5)HdfDeviceNode
. . . . . . 我們當(dāng)然沒必要在一篇文檔里列出所有的數(shù)據(jù)結(jié)構(gòu),只需先明白:
1)設(shè)備管理服務(wù)(DevmgrService)內(nèi)部可以管理若干Host;
2)每個Host內(nèi)部可以整合若干業(yè)務(wù)相近的設(shè)備;
3)每個Host可以拆分成兩個部分:DevHostServiceClnt 和 DevHostService;
4)每個DevHostService可以添加多個設(shè)備; 從上面的調(diào)用關(guān)系圖中,我們可以看到DevmgrServiceStartDeviceHosts()函數(shù)的主要行為是:
1)先獲取一個驅(qū)動安裝器(單例)對象;
2)解析系統(tǒng)配置信息,將其轉(zhuǎn)換成一個以HdfHostInfo為表項的列表,這個就對應(yīng)著系統(tǒng)里所有的host;
3)遍歷這張HdfHostInfo列表,為每個HdfHostInfo節(jié)點創(chuàng)建一個對應(yīng)的DevHostServiceClnt對象;
4)新創(chuàng)建的DevHostServiceClnt節(jié)點會被插入DevmgrService的hosts列表中;
5)針對每個HdfHostInfo節(jié)點,利用剛剛獲取的驅(qū)動安裝器具體啟動該host。 2.1.3.1獲取驅(qū)動安裝器 現(xiàn)在我們詳細(xì)看上圖中調(diào)用的關(guān)鍵函數(shù)。
- installer = DriverInstallerGetInstance();
復(fù)制代碼 先拿到一個驅(qū)動安裝器。
- struct IDriverInstaller *DriverInstallerGetInstance()
- {
- static struct IDriverInstaller *installer = NULL;
- if (installer == NULL) {
- installer = (struct IDriverInstaller *)HdfObjectManagerGetObject(HDF_OBJECT_ID_DRIVER_INSTALLER);
- }
- return installer;
- }
- 又看到HdfObjectManagerGetObject(),于是我們查前文那張表,可以找到驅(qū)動安裝器對應(yīng)的創(chuàng)建函數(shù)是DriverInstallerCreate():
- 【drivers/hdf/frameworks/core/manager/src/Hdf_driver_installer.c】
- struct HdfObject *DriverInstallerCreate(void)
- {
- static bool isDriverInstInit = false;
- static struct DriverInstaller driverInstaller;
- if (!isDriverInstInit) {
- DriverInstallerConstruct(&driverInstaller);
- isDriverInstInit = true;
- }
- return (struct HdfObject *)&driverInstaller;
- }
- 用的是一個單例的DriverInstaller對象。
- 2.1.3.2 獲取HdfHostInfo列表
- 啟動所有hosts的第二步,是獲取一個HdfHostInfo列表:
- HdfAttributeManagerGetHostList(&hostList)
- 我們摘選該函數(shù)的主要句子,如下:
- 【drivers/hdf/lite/manager/src/Hdf_attribute_manager.c】
- bool HdfAttributeManagerGetHostList(struct HdfSList *hostList)
- {
- . . . . . .
- hdfManagerNode = GetHdfManagerNode(HcsGetRootNode());
- . . . . . .
- hostNode = hdfManagerNode->child;
- while (hostNode != NULL) {
- struct HdfHostInfo *hostInfo = HdfHostInfoNewInstance();
- . . . . . .
- if (!GetHostInfo(hostNode, hostInfo)) {
- HdfHostInfoFreeInstance(hostInfo);
- hostInfo = NULL;
- hostNode = hostNode->sibling;
- continue;
- }
- hostInfo->hostId = hostId;
- if (!HdfSListAddOrder(hostList, &hostInfo->node, HdfHostListCompare)) {
- HdfHostInfoFreeInstance(hostInfo);
- hostInfo = NULL;
- hostNode = hostNode->sibling;
- continue;
- }
- hostId++;
- hostNode = hostNode->sibling;
- }
- return true;
- }
復(fù)制代碼 我們稍微擴展一點知識來說明一下。在鴻蒙系統(tǒng)中,有一些系統(tǒng)級的配置文件,叫做HCS文件。系統(tǒng)可以利用類似hc-gen這樣的工具,根據(jù)配置文件生成二進制碼。當(dāng)HDF啟動時,它會將二進制信息傳給DriverConfig模塊。該模塊會將二進制碼轉(zhuǎn)換成配置樹,并向開發(fā)者提供API去查詢這棵樹。
配置樹的根節(jié)點是g_hcsTreeRoot,節(jié)點類型為DeviceResourceNode。這棵配置樹里有一個特殊的節(jié)點,具有“hdf_manager”屬性,上面代碼中調(diào)用GetHdfManagerNode()一句,就是在獲取這個特殊節(jié)點。接著,上面的代碼里會嘗試遍歷該節(jié)點的所有child,并將每個child的信息整理進一個HdfHostInfo對象里。注意此時就會給HdfHostInfo分派一個hostId了,這個hostId后續(xù)還會用到。所有讀出的HdfHostInfo節(jié)點會按照其內(nèi)記錄的優(yōu)先級進行排序,并連成一個列表,優(yōu)先級越高越靠近表頭。
2.1.3.3 遍歷HdfHostInfo列表 得到HdfHostInfo列表后,緊接著就會嘗試遍歷這張表。因為每個HdfHostInfo節(jié)點代表的就是一個host,所以每讀取一個HdfHostInfo,就會對應(yīng)地生成一個DevHostServiceClnt對象。這些生成的DevHostServiceClnt都會插入到DevmgrService的hosts列表中。
每讀取一個HdfHostInfo信息后,就會利用驅(qū)動安裝器,啟動對應(yīng)的host。
2.1.3.4啟動host
啟動host的動作是installer->StartDeviceHost()一步,它的調(diào)用關(guān)系如下: 大家還記得前文我說過,每個Host可以拆分成兩個部分:DevHostServiceClnt 和 DevHostService。這個就體現(xiàn)在上面的調(diào)用關(guān)系里。 StartDeviceHost一開始就會創(chuàng)建一個DevHostService對象,
【drivers/hdf/frameworks/core/manager/src/Hdf_driver_installer.c】
- static int DriverInstallerStartDeviceHost(uint32_t devHostId, const char *devHostName)
- {
- struct IDevHostService *hostServiceIf = DevHostServiceNewInstance(devHostId, devHostName);
- if ((hostServiceIf == NULL) || (hostServiceIf->StartService == NULL)) {
- HDF_LOGE(“hostServiceIf or hostServiceIf->StartService is null“);
- return HDF_FAILURE;
- }
- int ret = hostServiceIf->StartService(hostServiceIf);
- if (ret != HDF_SUCCESS) {
- HDF_LOGE(“Start host service failed, ret is: %d“, ret);
- DevHostServiceFreeInstance(hostServiceIf);
- }
- return ret;
- }
復(fù)制代碼 隨后調(diào)用的StartService,實際上對應(yīng)DevHostServiceStartService()函數(shù):
【drivers/hdf/frameworks/core/host/src/Devhost_service.c】
- static int DevHostServiceStartService(struct IDevHostService *service)
- {
- struct DevHostService *hostService = (struct DevHostService*)service;
- if (hostService == NULL) {
- HDF_LOGE(“Start device service failed, hostService is null“);
- return HDF_FAILURE;
- }
- return DevmgrServiceClntAttachDeviceHost(hostService->hostId, service);
- }
復(fù)制代碼 此處調(diào)用的DevmgrServiceClntAttachDeviceHost()函數(shù),內(nèi)部涉及的內(nèi)容挺多,我打算在下一篇文檔里再細(xì)說,F(xiàn)在我們已經(jīng)對“啟動DeviceManager”的流程有了一點初步的認(rèn)識,為了便于理解里面host的部分,我們畫一張示意圖總結(jié)一下,繪圖如下: 好了,今天就先寫到這里,更多關(guān)于HDF的內(nèi)容會在后續(xù)文檔中闡述,希望對大家有點幫助。 文章轉(zhuǎn)自:侯亮(悠然紅茶) |
|