Hi3861的SAMGR--系统服务框架子系统-1-初识+代码结构 原创 精华

Hi3861的SAMGR--系统服务框架子系统-1

初识+代码结构

liangkz 2021.06.01 v1.0

 

1. 初步了解

先看README文档，位于LTS/foundation/distributedschedule/samgr_lite/README_zh.md。

我们对其中的部分内容先做一下初步的理解。

系统服务框架[system ability (SA) framework]，是为了屏蔽不同的硬件架构、不同的平台资源、不同的运行形态等软硬件差异，而提供的统一的系统服务开发框架。

根据处理器的不同架构，如RISC-V架构(基于精简指令集RISC的开源架构)、ARM架构(如ARM的Cortex-M/Cortex-A等)、x86架构(主要用于PC市场，目前鸿蒙暂不支持，但指不定哪天就宣布支持了)等，目前分为两类硬件平台，以下简称M核(平台)、A核(平台)。

• M核：处理器架构为Cortex-M或同等处理能力的硬件平台，系统内存一般低于512KB，无文件系统或者仅提供一个可有限使用的轻量级文件系统，遵循CMSIS接口规范。
• A核：处理器架构为Cortex-A或同等处理能力的硬件平台，内存资源大于512KB，文件系统完善，可存储大量数据，遵循POSIX接口规范。

 

系统服务框架基于面向服务的架构(SOA，Service-Oriented Architecture)，提供了服务(service)开发、服务的子功能(feature)开发、对外接口(IUnknown)的开发、以及多服务共进程、进程间服务调用等开发能力。其中：

• M核：包含服务开发、服务的子功能开发、对外接口的开发以及多服务共进程的开发框架。
• A核：在M核能力基础之上，包含了进程间服务调用、进程间服务调用权限控制、进程间服务接口的开发等能力。

依赖关系上：

• M核：系统依赖bootstrap服务，在系统启动函数中调用HOS_SystemInit()函数。
• A核：系统依赖samgr库，在main函数中调用SAMGR_Bootstrap()函数。

 

我的简单理解：

• samgr是一个系统服务开发框架，开发者可以根据这里规定的规则，开发自定义的服务和功能(service+feature)、接口等等。

     示例程序在Hi3861/applications/sample/wifi-iot/app/samgr/，打开BUILD.gn的编译规则即可参与编译。

     示例程序可能会有编译错误，可以获取gitee上的最新代码对比着进行修改，或者参考《WiFi IoT 编译samgr模块》 进行修改。

     编译出来的程序可能会出现kernel panic，我估计很大的原因是一次性注册和启动的service/feature/task太多了，导致系统资源耗尽引起的，所以最好还是只编译部分需要验证的示例程序，不要一次全部编译完。我后面附上的log，就是只编译了service_example.c和feature_example.c抓取的。

• samgr提供了对所有service、feature、接口的统一管理，包含了跨设备的service/feature的管理和调度，这是鸿蒙系统非常核心的特性之一。

 

2. 代码目录结构

先看一下LTS/foundation/distributedschedule/samgr_lite/ 的代码结构：

看上去相当复杂。

再看对应的Hi3861/foundation/distributedschedule/ 代码结构：

两相对比，其实大致上是一样的。

去 Hi3861/foundation/distributedschedule/service/samgr_lite/ 目录下看BUILD.gn文件的构建规则，把只在A核上编译的部分灰化，如上表，剩下的基本上就是M核要用到的了。

 

本文先只从Hi3861工程的角度来看samgr子系统，所以代码基本上只需要看：

Hi3861/foundation/distributedschedule/service/samgr_lite/communication/broadcast/

Hi3861/foundation/distributedschedule/service/samgr_lite/samgr/source/

因为samgr“依赖bootstrap服务”，所以连带也要看 Hi3861/base/startup/services/bootstrap_lite/ 的代码。

至于：

• Hi3861/foundation/distributedschedule/service/samgr_lite/samgr/adapter/ 

     这是对调用者屏蔽了平台差异性的统一接口的声明和实现，暂不进一步深究。

• Hi3861/foundation/distributedschedule/service/samgr_lite/samgr/registry/

     这里定义了三个弱引用的API：

     SAMGR_RegisterServiceApi()

     SAMGR_FindServiceApi()

     SAMGR_RegisterFactory() 

     它们在/samgr_server/source/ samgr_server.c 中有实现，估计和跨设备的服务调用有关，但是M核不编译samgr_server，所以，M核的上述三个API其实没做什么工作，这里也暂不进一步深究。

 

这样清理一下相关代码和模块关系就会发现简单很多，入手也会相对容易一些，下面我们就开始“Read the f**king source code :)”。

 

【说明：删除下面这一小节，由新的帖子《Hi3861的SAMGR--系统服务框架子系统-3》替代】

3. 大概流程

Hi3861平台在启动到HOS_SystemInit()时，

void HOS_SystemInit(void)
{
    ......
    printf("[system_init] [7-4]: SYS_INIT(service)=====================\n");
    SYS_INIT(service);

    printf("[system_init] [7-5]: SYS_INIT(feature)=====================\n");
    SYS_INIT(feature);
    ......
    printf("[system_init] [7-7]: SAMGR_Bootstrap()=====================\n");
    SAMGR_Bootstrap();
}

会分别通过上面三步来：向samgr注册系统服务(service)、注册系统服务提供的功能(feature)、通过samgr启动并开始管理系统服务和功能。

 

从抓回来的log看：

[system_init] [7-4]: SYS_INIT(service)=====================

[bootstrap_service] SYS_SERVICE_INIT(Init): Bootstrap

[samgr_lite] SAMGR_GetInstance(mutex=NULL): NO SAMGR instance, Init() to create ONE

[samgr_lite] Init. g_samgrImpl

[samgr_lite] Init. mutex[956036]. sharedPool[0-8] reset to 0. status=0[BOOT_SYS]

[samgr_lite] SAMGR_GetInstance(mutex=956036)

[samgr_lite] RegisterService(Name:Bootstrap)->Sid[0]

 

[broadcast_service] SYS_SERVICE_INIT(Init): Broadcast

[samgr_lite] RegisterService(Name:Broadcast)->Sid[1]

 

[hiview_service] SYS_SERVICE_INIT(Init): hiview

[samgr_lite] RegisterService(Name:hiview)->Sid[2]

[samgr_lite] RegisterFeatureApi(serviceName[hiview], feature[(null)])

[hiview_service] Init.InitHiviewComponent.

 

[system_init] [7-5]: SYS_INIT(feature)=====================

[pub_sub_feature] Init. SYS_FEATURE_INIT(Init) g_broadcastFeature: Provider and subscriber

[samgr_lite] RegisterFeature(serviceName:Broadcast, featureName:Provider and subscriber)->Fid[0]

[pub_sub_implement] BCE_CreateInstance: set g_pubSubImplement.feature = &g_broadcastFeature

[samgr_lite] RegisterFeatureApi(serviceName[Broadcast], feature[Provider and subscriber])

会注册三个系统服务和一个系统feature。

 

        第一个注册的系统服务是Bootstrap，这个时候samgr还没有实例，所以需要先初始化samgr的全局实例g_samgrImpl，然后才能通过RegisterService((Service *)&bootstrap)来向g_samgrImpl注册bootstrap服务。这时候g_samgrImpl会通过SAMGR_CreateServiceImpl()来为bootstrap创建一个ServiceImpl 对象，将该对象加入g_samgrImpl.services向量中，并返回它在向量中的位置[0]，以此作为bootstrap 的ServiceID[0](文中或log中简写为Sid，同样FeatureID简写为Fid，QueueID简写为Qid)。

        接下来注册的第二个服务broadcast和第三个服务hiview，就可以直接通过RegisterService((Service *)Xxx)记录进g_samgrImpl.services向量里了，Sid分别是[1]/[2]。

        接下来再注册broadcast service的feature：PUB_SUB_FEATURE。feature的注册和运行需要依赖于对应的service，一个service可以有0个、1个或多个feature。通过RegisterFeature(service, feature)的调用，samgr也会先生成一个FeatureImpl对象，再将该对象加入到 g_samgrImpl.services向量中对应的service 的ServiceImpl 对象的向量features中去，以完成feature的注册。这一句看起来比较绕，简单来说，就是g_samgrImpl的services向量管理着所有登记在册的services的ServiceImpl ，而每个ServiceImpl又通过自己的features向量管理自己所有的features。【更具体的实现过程，后面会有详细的代码分析。】

        在接下来的系统运行中，serviceName/serviceID(Sid) 和featureName/featureID(Fid) 都是非常重要的信息，samgr可以通过它们来找到对应的ServiceImpl/FeatureImpl对象，并提供相应的服务/功能。

 

[system_init] [7-7]: SAMGR_Bootstrap()=====================

[samgr_lite] SAMGR_Bootstrap. Begin:    size=3

        InitializeAllServices: size=3

        Add service: Bootstrap   to TaskPool: 0x0...

                                                   TaskPool: 0xfa448...

                                                           Qid: 956360...

        Add service: Broadcast   to TaskPool: 0x0...

                                                   TaskPool: 0xfaab8...

                                                           Qid: 956404...

        Add service: hiview      to TaskPool: 0x0...

                                                 TaskPool: 0xfac78...

                                                         Qid: 956448...

[task_manager] SAMGR_StartTaskPool:

        CreateTask[Bootstrap(Tid: 0xe8780), size(8192), Prio(25)]-OK!

[task_manager] SAMGR_StartTaskPool:

        CreateTask[Broadcast(Tid: 0xe871c), size(4096), Prio(32)]-OK!

[task_manager] SAMGR_StartTaskPool:

        CreateTask[hiview(Tid: 0xe87e4), size(2048), Prio(24)]-OK!

[samgr_lite] SAMGR_Bootstrap. End.

这里就是samgr开始为各个登记在g_samgrImpl.services向量里的service创建Queue和TaskPool这些运行环境了，在SAMGR_StartTaskPool() 这一步依次创建和启动service任务/线程，线程入口是TaskEntry()函数，位于

Hi3861/foundation/distributedschedule/services/samgr_lite/samgr/source/task_manager.c 文件内。

各个服务的TaskEntry线程，监控着各自的消息队列Queue，从中检出消息，获取Exchange封装的数据，根据里面的相关标记调用相关的msg handler来进行对应的处理。

 

上面的流程仅仅是启动了用SYS_SERVICE_INIT()和SYS_FEATURE_INIT() 标记的service和feature，而通过SYSEX_SERVICE_INIT/APP_SERVICE_INIT/ SYSEX_FEATURE_INIT/APP_FEATURE_INIT 标记的service和feature(如在前面提到的示例程序samgr里定义的一部分service和feature)，则会在系统启动到 BOOT_APP 这一步时，通过发送消息BOOT_SYS_COMPLETED到Bootstrap的消息队列中，让Bootstrap调用MessageHandle()来处理该消息：通过调用INIT_APP_CALL(service)和INIT_APP_CALL(feature)来完成APP service和Feature的启动，从而提供用户定义的服务和功能。

 

上面是service/feature的注册和启动的大概过程，主要的工作都是samgr来实现的，这就是samgr_lite组件的基础代码部分所提供的功能。

log和简单的步骤描述，见附件log。

 

接下来我会对一些重要的结构体进行分解，对部分流程进行详细的分析。

 

[未完待续......]