基本概念
LiteIPC
是OpenHarmony LiteOS-A
内核提供的一种新型IPC
(Inter-Process Communication,即进程间通信)机制,为轻量级进程间通信组件,为面向服务的系统服务框架提供进程间通信能力,分为内核实现和用户态实现两部分,其中内核实现完成进程间消息收发、IPC内存管理、超时通知和死亡通知等功能;用户态提供序列化和反序列化能力,并完成IPC
回调消息和死亡消息的分发。
我们主要讲解内核态实现部分,本想一篇说完,但发现它远比想象中的复杂和重要,所以分两篇说,通讯内容和通讯机制。通讯的内容就是消息,围绕着消息展开的结构体多达10
几个,捋不清它们之间的关系肯定是搞不懂通讯的机制,所以咱们得先搞清楚关系再说流程。下图是笔者读完LiteIPC
模块后绘制的消息封装图,可以说LiteIPC
是内核涉及结构体最多的模块,请消化理解,本篇将围绕它展开。
[图片上传失败…(image-a29828-1715581843494)]
系列篇多次提过,内核的每个模块都至少围绕着一个重要结构体展开,抓住了它顺瓜摸藤就能把细节抹的清清楚楚,于LiteIPC
,这个结构体就是IpcMsg
。
运行机制
typedef struct {//IPC 消息结构体
MsgType type; /**< cmd type, decide the data structure below | 命令类型,决定下面的数据结构*/
SvcIdentity target; /**< serviceHandle or targetTaskId, depending on type | 因命令类型不同而异*/
UINT32 code; /**< service function code | 服务功能代码*/
UINT32 flag; ///< 标签
#if (USE_TIMESTAMP == 1)
UINT64 timestamp; ///< 时间戳,用于验证
#endif
UINT32 dataSz; /**< size of data | 消息内容大小*/
VOID *data; ///< 消息的内容,真正要传递的消息,这个数据内容是指spObjNum个数据的内容,定位就靠offsets
UINT32 spObjNum; ///< 对象数量, 例如 spObjNum = 3时,offsets = [0,35,79],代表从data中读取 0 - 35给第一个对象,依次类推
VOID *offsets; ///< 偏移量,注意这里有多少个spObjNum就会有多少个偏移量,详见 CopyDataFromUser 来理解
UINT32 processID; /**< filled by kernel, processId of sender/reciever | 由内核提供,发送/接收消息的进程ID*/
UINT32 taskID; /**< filled by kernel, taskId of sender/reciever | 由内核提供,发送/接收消息的任务ID*/
#ifdef LOSCFG_SECURITY_CAPABILITY
UINT32 userID; ///< 用户ID
UINT32 gid; ///< 组ID
#endif
} IpcMsg;
解读
-
第一个
type
,通讯的本质就是你来我往,异常当然也要考虑typedef enum { MT_REQUEST, ///< 请求 MT_REPLY, ///< 回复 MT_FAILED_REPLY,///< 回复失败 MT_DEATH_NOTIFY,///< 通知死亡 MT_NUM } MsgType;
-
第二个
target
,LiteIPC
中有两个主要概念,一个是ServiceManager
,另一个是Service
。整个系统只能有一个ServiceManager
,而Service
可以有多个。ServiceManager
有两个主要功能:一是负责Service
的注册和注销,二是负责管理Service
的访问权限(只有有权限的任务Task
可以向对应的Service
发送IPC
消息)。首先将需要接收IPC
消息的任务通过ServiceManager
注册成为一个Service
,然后通过ServiceManager
为该Service
任务配置访问权限,即指定哪些任务可以向该Service
任务发送IPC<