品读鸿蒙HDF架构(一)|解读鸿蒙源码

原创
2020/09/25 14:26
阅读数 3.1W

品读鸿蒙HDF架构(一)

侯亮

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)HdfHostInfo
2)DevHostServiceClnt
3)DevHostService
4)HdfDevice
5)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;
}

随后调用的StartService,实际上对应DevHostServiceStartService()函数:
【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);
}

此处调用的DevmgrServiceClntAttachDeviceHost()函数,内部涉及的内容挺多,我打算在下一篇文档里再细说。现在我们已经对“启动DeviceManager”的流程有了一点初步的认识,为了便于理解里面host的部分,我们画一张示意图总结一下,绘图如下:

好了,今天就先写到这里,更多关于HDF的内容会在后续文档中阐述,希望对大家有点帮助。

(本文参与了「解读鸿蒙源码」技术征文,欢迎正在阅读的你也加入。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
0 评论
5 收藏
8
分享
返回顶部
顶部