| 编辑推荐: |
本文主要带领大家通过研读鸿蒙系统源代码，并对其深究解释，
希望对您的学习有所帮助。
本文来自于CSDN，由火龙果软件Alice编辑、推荐。 |
|
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相关的部分：
void SystemInit(void)
{
. . . . . .
#ifdef LOSCFG_DRIVERS_HDF
if (DeviceManagerStart()) {
PRINT_WARN("No drivers need load by hdf manager!");
}
#endif
. . . . . .
} |
2.1 启动DeviceManager
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机制提供的一个对象管理器，相关代码如下：
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：
| static const struct HdfObjectCreator g_liteObjectCreators[] |
基于读到的代码，我们可以画出这个表格：
概念还是比较简单的，如果系统中的DevmgrService单例对象已经存在，就使用之。否则就利用HDF对象管理器创建一个DevmgrService对象。对于HDF对象管理器而言，不同类型的HDF对象，需要用到不同的创建函数，所以要查一下上表。比如DevmgrService对应的创建函数就是DevmgrServiceCreate()，该函数代码如下：
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的构造函数如下：
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.2 HdfIoServiceBind()
启动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()函数。
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()：
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) |
我们摘选该函数的主要句子，如下：
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对象，
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()函数：
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的部分，我们画一张示意图总结一下，绘图如下：
|
