品读鸿蒙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的内容会在后续文档中阐述,希望对大家有点帮助。
(本文参与了「解读鸿蒙源码」技术征文,欢迎正在阅读的你也加入。)