【HarmonyOS】品读鸿蒙HDF架构（一）

https://my.oschina.net/youranhongcha/blog/4648205

本帖最后由 l_xy 于 2020-10-18 17:38 编辑

原文链接：https://my.oschina.net/youranhongcha/blog/4648205

1.铺垫一下

鸿蒙系统终于公开源代码了，正可谓“千呼万唤始出来”。笔者也手痒下载了一套代码，并研读了一二。这里就先编写一篇关于HDF的文档。

其实，不同读码人都会有各自读代码的习惯和切入点，我之所以从HDF入手，完全是出于偶然。因为在一开始读官方文档时，看到说一部机器可以操作另一部机器的设备，为此，设备需要有一个重要的PublishService()函数。这种跨设备操作的能力也是鸿蒙的一大特色，应该比较有趣，于是就以这个PublishService()为切入点，开始研读代码，慢慢就涉及了HDF的更多知识，现在是时候整理出来了。

所谓HDF，应该是HARMony Driver Fundation的缩写，说到底是鸿蒙形成的一套管理设备驱动的框架模型，也被称为“驱动子系统”。在官网的文档里介绍说这个驱动子系统具有以下重要能力：

弹性化的框架能力
规范化的驱动接口
组件化的驱动模型
归一化的配置界面

读完这四句话，不免让人觉得好像明白了什么，又好像什么都没明白。好吧，我还是按自己的习惯直接读代码吧。

为了便于理解代码，我习惯于把软件图形化。为此，我介绍一点我的图形表达方法。在我读Java代码时，如果要表达A类对象的某个成员引用了另一个B类对象，我常常会这样绘制：

但是HDF的代码是用C写的，所以对应的图形表达法也要有所变化。我们要区分一下：1）A结构以某成员组合了另一个B结构；2）A结构某成员是个指向B的指针；这两种情况可以分别表示为：

另外，有时候HDF会使用C语言的一些技巧进行链表表达或基类转换，那么上面的图形画出来就会很累赘，针对这种情况，我有时候会这样表达（以DevmgrService结构为例）：

可以看出，DevmgrService继承于IDevmgrService，而IDevmgrService又在起始处组合了一个HdfDeviceObject（有时候也可以说是继承于HdfDeviceObject）。也就是说：1）DevmgrService的起始地址；2）DevmgrService内部IDevmgrService部分的起始地址；3）IDevmgrService内部HdfDeviceObject部分的起始地址；这3个起始地址其实是同一处。用这种表达法，我们就不必画出3个分离的框图了。

好了，铺垫部分就先写这么多，下面我们来看HDF的实际内容。

2.DevmgrService和Dev Host

我们以hi3516 dv300为例，其系统一启动，会运行到SystemInit()，其中会调用DeviceManagerStart()启动与HDF相关的部分：【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
. . . . . .
}

复制代码

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);
}

复制代码

简单地说，要启动DeviceManager服务，就得先获取一个DevmgrService实例，然后调用它的StartService()，又因为DevmgrService继承于IDevmgrService，所以可以强制转换成IDevmgrService。

2.1.1获取DevmgrService单例

获取实例时，其实用到了HDF机制提供的一个对象管理器，相关代码如下：

【drivers/hdf/frameworks/core/manager/src/Devmgr_service.c】

struct IDevmgrService *DevmgrServiceGetInstance()
{
static struct IDevmgrService *instance = NULL; // 注意是static的，表示是个静态单例
if (instance == NULL) {
instance = (struct IDevmgrService *)HdfObjectManagerGetObject(HDF_OBJECT_ID_DEVMGR_SERVICE);
}
return instance;
}

复制代码

以后我们会看到，这个HdfObjectManagerGetObject()会在多个地方调用，以便获取不同的HDF对象。说起来也简单，HDF机制里有一张表，记录着该如何创建、释放一些重要的HDF对象，该表格为g_liteObjectCreators：【drivers/hdf/lite/manager/src/Devlite_object_config.c】

static const struct HdfObjectCreator g_liteObjectCreators[]

复制代码

基于读到的代码，我们可以画出这个表格：

HDF类型ID	创建函数	释放函数
HDF_OBJECT_ID_DEVMGR_SERVICE	DevmgrServiceCreate	DevmgrServiceRelease
HDF_OBJECT_ID_DEVSVC_MANAGER	DevSvcManagerCreate	DevSvcManagerRelease
HDF_OBJECT_ID_DEVHOST_SERVICE	DevHostServiceCreate	DevHostServiceRelease
HDF_OBJECT_ID_DRIVER_INSTALLER	DriverInstallerCreate	NULL
HDF_OBJECT_ID_DRIVER_LOADER	HdfDriverLoaderCreate	NULL
HDF_OBJECT_ID_DEVICE	HdfDeviceCreate	HdfDeviceRelease
HDF_OBJECT_ID_DEVICE_TOKEN	HdfDeviceTokenCreate	HdfDeviceTokenRelease
HDF_OBJECT_ID_DEVICE_SERVICE	DeviceNodeExtCreate	DeviceNodeExtRelease

概念还是比较简单的，如果系统中的DevmgrService单例对象已经存在，就使用之。否则就利用HDF对象管理器创建一个DevmgrService对象。对于HDF对象管理器而言，不同类型的HDF对象，需要用到不同的创建函数，所以要查一下上表。比如DevmgrService对应的创建函数就是DevmgrServiceCreate()，该函数代码如下：【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，有小问题！
}

复制代码

在“创建”时，如果发现是首次创建，则调用一个类似构造函数的DevmgrServiceConstruct()函数，来初始化对象里的函数表。这种做法是用C语言实现面向对象概念的常用做法。不过，此处的代码有一个小bug，即最后那个强制转换，从目前看到的代码来说，DevmgrService间接继承于HdfDeviceObject，而HdfDeviceObject并不继承于HdfObject，所以是不应该这样强制转换的，除非HdfDeviceObject的第一个成员从“IDeviceIoService*”改为“IDeviceIoService”，我估计最早的代码就是IDeviceIoService，后来因为某些原因，变成了指针形式，至于以后具体该怎么修正，这个就让鸿蒙的工程师去费脑筋吧。DevmgrService的构造函数如下：【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;
}

复制代码

2.1.2HdfIoServiceBind()

启动DeviceManager时，第二个重要的动作是调用HdfIoServiceBind()：

struct HdfIoService *ioService = HdfIoServiceBind(DEV_MGR_NODE, DEV_MGR_NODE_PERM);

这一步在做什么呢？我们可以这样理解，DevmgrService作为一个核心的系统服务，我们希望能像访问虚文件系统的文件那样打开它，并进一步向它传递诸如AttachDevice、StartServie......这样的语义。这些语义最终会执行到上面列举的DevmgrServiceAttachDevice、DevmgrServiceStartService等函数。

我们不必列举太多代码，下面是我绘制的一张关于DeviceManagerStart()的调用关系示意图，可供参考：

图中已经明确注明，DevmgrService在虚文件系统里对应的路径应该是“/dev/dev_mgr”，而上面调用HdfIoServiceBind()后，实际上建立了一个文件系统的inode节点，示意图如下：

HdfVNodeAdapter的target在最后赋值为(struct HdfObject*)&instance->object，说到底其实就是指向了DevmgrService。

2.1.3执行DevmgrService的StartService

接下来是启动DeviceManager的第三步，调用instance->StartService()，这一步其实是在调用DevmgreviceStartService()函数。【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);
}

复制代码

主要就是在调用一个DevmgrServiceStartDeviceHosts()函数。这个函数应该算是个重量级函数，它会负责建立起DevmgrService内部主要的数据结构。我们先绘制一下该函数第一层次的调用关系，如下图：

在进一步深入代码细节之前，我们最好先大概说明一下。在鸿蒙HDF架构里，有一个“设备Host”的概念，根据官方的文档，我们大概可以知道，一个Host用于整合若干业务相近的设备，这个原则被称为相似相容原则。为了实现这个原则，HDF构造了一系列数据结构，我们列举一下：1）HdfHostInfo2）DevHostServiceClnt3）DevHostService4）HdfDevice5）HdfDeviceNode. . . . . .

我们当然没必要在一篇文档里列出所有的数据结构，只需先明白：1）设备管理服务（DevmgrService）内部可以管理若干Host；2）每个Host内部可以整合若干业务相近的设备；3）每个Host可以拆分成两个部分：DevHostServiceClnt 和 DevHostService；4）每个DevHostService可以添加多个设备；

从上面的调用关系图中，我们可以看到DevmgrServiceStartDeviceHosts()函数的主要行为是：1）先获取一个驱动安装器（单例）对象；2）解析系统配置信息，将其转换成一个以HdfHostInfo为表项的列表，这个就对应着系统里所有的host；3）遍历这张HdfHostInfo列表，为每个HdfHostInfo节点创建一个对应的DevHostServiceClnt对象；4）新创建的DevHostServiceClnt节点会***入DevmgrService的hosts列表中；5）针对每个HdfHostInfo节点，利用刚刚获取的驱动安装器具体启动该host。

2.1.3.1获取驱动安装器

现在我们详细看上图中调用的关键函数。installer = DriverInstallerGetInstance();先拿到一个驱动安装器。

struct IDriverInstaller *DriverInstallerGetInstance()
{
static struct IDriverInstaller *installer = NULL;
if (installer == NULL) {
installer = (struct IDriverInstaller *)HdfObjectManagerGetObject(HDF_OBJECT_ID_DRIVER_INSTALLER);
}
return installer;
}
又看到HdfObjectManagerGetObject()，于是我们查前文那张表，可以找到驱动安装器对应的创建函数是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)我们摘选该函数的主要句子，如下：【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;
}

复制代码

我们稍微扩展一点知识来说明一下。在鸿蒙系统中，有一些系统级的配置文件，叫做HCS文件。系统可以利用类似hc-gen这样的工具，根据配置文件生成二进制码。当HDF启动时，它会将二进制信息传给DriverConfig模块。该模块会将二进制码转换成配置树，并向开发者提供API去查询这棵树。

配置树的根节点是g_hcsTreeRoot，节点类型为DeviceResourceNode。这棵配置树里有一个特殊的节点，具有“hdf_manager”属性，上面代码中调用GetHdfManagerNode()一句，就是在获取这个特殊节点。接着，上面的代码里会尝试遍历该节点的所有child，并将每个child的信息整理进一个HdfHostInfo对象里。注意此时就会给HdfHostInfo分派一个hostId了，这个hostId后续还会用到。所有读出的HdfHostInfo节点会按照其内记录的优先级进行排序，并连成一个列表，优先级越高越靠近表头。

2.1.3.3遍历HdfHostInfo列表

得到HdfHostInfo列表后，紧接着就会尝试遍历这张表。因为每个HdfHostInfo节点代表的就是一个host，所以每读取一个HdfHostInfo，就会对应地生成一个DevHostServiceClnt对象。这些生成的DevHostServiceClnt都会插入到DevmgrService的hosts列表中。

每读取一个HdfHostInfo信息后，就会利用驱动安装器，启动对应的host。

2.1.3.4启动host

启动host的动作是installer->StartDeviceHost()一步，它的调用关系如下：

大家还记得前文我说过，每个Host可以拆分成两个部分：DevHostServiceClnt 和 DevHostService。这个就体现在上面的调用关系里。

StartDeviceHost一开始就会创建一个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;
}