Hi3861的SAMGR--系統(tǒng)服務(wù)框架子系統(tǒng)-1
51CTO和華為官方合作共建的鴻蒙技術(shù)社區(qū)
1. 初步了解
先看README文檔，位于LTS/foundation/distributedschedule/samgr_lite/README_zh.md。
我們對其中的部分內(nèi)容先做一下初步的理解。
系統(tǒng)服務(wù)框架[system ability (SA) framework]，是為了屏蔽不同的硬件架構(gòu)、不同的平臺資源、不同的運(yùn)行形態(tài)等軟硬件差異，而提供的統(tǒng)一的系統(tǒng)服務(wù)開發(fā)框架。
根據(jù)處理器的不同架構(gòu)，如RISC-V架構(gòu)(基于精簡指令集RISC的開源架構(gòu))、ARM架構(gòu)(如ARM的Cortex-M/Cortex-A等)、x86架構(gòu)(主要用于PC市場，目前鴻蒙暫不支持，但指不定哪天就宣布支持了)等，目前分為兩類硬件平臺，以下簡稱M核(平臺)、A核(平臺)。
- M核：處理器架構(gòu)為Cortex-M或同等處理能力的硬件平臺，系統(tǒng)內(nèi)存一般低于512KB，無文件系統(tǒng)或者僅提供一個(gè)可有限使用的輕量級文件系統(tǒng)，遵循CMSIS接口規(guī)范。
- A核：處理器架構(gòu)為Cortex-A或同等處理能力的硬件平臺，內(nèi)存資源大于512KB，文件系統(tǒng)完善，可存儲大量數(shù)據(jù)，遵循POSIX接口規(guī)范。
系統(tǒng)服務(wù)框架基于面向服務(wù)的架構(gòu)(SOA，Service-Oriented Architecture)，提供了服務(wù)(service)開發(fā)、服務(wù)的子功能(feature)開發(fā)、對外接口(IUnknown)的開發(fā)、以及多服務(wù)共進(jìn)程、進(jìn)程間服務(wù)調(diào)用等開發(fā)能力。其中：
- M核：包含服務(wù)開發(fā)、服務(wù)的子功能開發(fā)、對外接口的開發(fā)以及多服務(wù)共進(jìn)程的開發(fā)框架。
- A核：在M核能力基礎(chǔ)之上，包含了進(jìn)程間服務(wù)調(diào)用、進(jìn)程間服務(wù)調(diào)用權(quán)限控制、進(jìn)程間服務(wù)接口的開發(fā)等能力。
依賴關(guān)系上：
- M核：系統(tǒng)依賴bootstrap服務(wù)，在系統(tǒng)啟動函數(shù)中調(diào)用HOS_SystemInit()函數(shù)。
- A核：系統(tǒng)依賴samgr庫，在main函數(shù)中調(diào)用SAMGR_Bootstrap()函數(shù)。
我的簡單理解：
- samgr是一個(gè)系統(tǒng)服務(wù)開發(fā)框架，開發(fā)者可以根據(jù)這里規(guī)定的規(guī)則，開發(fā)自定義的服務(wù)和功能(service+feature)、接口等等。
示例程序在Hi3861/applications/sample/wifi-iot/app/samgr/，打開BUILD.gn的編譯規(guī)則即可參與編譯。
示例程序可能會有編譯錯(cuò)誤，可以獲取gitee上的最新代碼對比著進(jìn)行修改，或者參考《WiFi IoT 編譯samgr模塊》 進(jìn)行修改。
編譯出來的程序可能會出現(xiàn)kernel panic，我估計(jì)很大的原因是一次性注冊和啟動的service/feature/task太多了，導(dǎo)致系統(tǒng)資源耗盡引起的，所以最好還是只編譯部分需要驗(yàn)證的示例程序，不要一次全部編譯完。我后面附上的log，就是只編譯了service_example.c和feature_example.c抓取的。
- samgr提供了對所有service、feature、接口的統(tǒng)一管理，包含了跨設(shè)備的service/feature的管理和調(diào)度，這是鴻蒙系統(tǒng)非常核心的特性之一。
2. 代碼目錄結(jié)構(gòu)
先看一下LTS/foundation/distributedschedule/samgr_lite/ 的代碼結(jié)構(gòu)：
看上去相當(dāng)復(fù)雜。
再看對應(yīng)的Hi3861/foundation/distributedschedule/ 代碼結(jié)構(gòu)：
兩相對比，其實(shí)大致上是一樣的。
去 Hi3861/foundation/distributedschedule/service/samgr_lite/ 目錄下看BUILD.gn文件的構(gòu)建規(guī)則，把只在A核上編譯的部分灰化，如上表，剩下的基本上就是M核要用到的了。
本文先只從Hi3861工程的角度來看samgr子系統(tǒng)，所以代碼基本上只需要看：
- Hi3861/foundation/distributedschedule/service/samgr_lite/communication/broadcast/
- Hi3861/foundation/distributedschedule/service/samgr_lite/samgr/source/
因?yàn)閟amgr“依賴bootstrap服務(wù)”，所以連帶也要看 Hi3861/base/startup/services/bootstrap_lite/ 的代碼。
至于：
- Hi3861/foundation/distributedschedule/service/samgr_lite/samgr/adapter/
這是對調(diào)用者屏蔽了平臺差異性的統(tǒng)一接口的聲明和實(shí)現(xiàn)，暫不進(jìn)一步深究。
- Hi3861/foundation/distributedschedule/service/samgr_lite/samgr/registry/
這里定義了三個(gè)弱引用的API：
- SAMGR_RegisterServiceApi()
- SAMGR_FindServiceApi()
- SAMGR_RegisterFactory()
它們在/samgr_server/source/ samgr_server.c 中有實(shí)現(xiàn)，估計(jì)和跨設(shè)備的服務(wù)調(diào)用有關(guān)，但是M核不編譯samgr_server，所以，M核的上述三個(gè)API其實(shí)沒做什么工作，這里也暫不進(jìn)一步深究。
這樣清理一下相關(guān)代碼和模塊關(guān)系就會發(fā)現(xiàn)簡單很多，入手也會相對容易一些，下面我們就開始“Read the f**king source code :)”。
3. 大概流程
Hi3861平臺在啟動到HOS_SystemInit()時(shí)，
- 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注冊系統(tǒng)服務(wù)(service)、注冊系統(tǒng)服務(wù)提供的功能(feature)、通過samgr啟動并開始管理系統(tǒng)服務(wù)和功能。
從抓回來的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])
會注冊三個(gè)系統(tǒng)服務(wù)和一個(gè)系統(tǒng)feature。
第一個(gè)注冊的系統(tǒng)服務(wù)是Bootstrap，這個(gè)時(shí)候samgr還沒有實(shí)例，所以需要先初始化samgr的全局實(shí)例g_samgrImpl，然后才能通過RegisterService((Service *)&bootstrap)來向g_samgrImpl注冊bootstrap服務(wù)。這時(shí)候g_samgrImpl會通過SAMGR_CreateServiceImpl()來為bootstrap創(chuàng)建一個(gè)ServiceImpl 對象，將該對象加入g_samgrImpl.services向量中，并返回它在向量中的位置[0]，以此作為bootstrap 的ServiceID[0](文中或log中簡寫為Sid，同樣FeatureID簡寫為Fid，QueueID簡寫為Qid)。
接下來注冊的第二個(gè)服務(wù)broadcast和第三個(gè)服務(wù)hiview，就可以直接通過RegisterService((Service *)Xxx)記錄進(jìn)g_samgrImpl.services向量里了，Sid分別是[1]/[2]。
接下來再注冊broadcast service的feature：PUB_SUB_FEATURE。feature的注冊和運(yùn)行需要依賴于對應(yīng)的service，一個(gè)service可以有0個(gè)、1個(gè)或多個(gè)feature。通過RegisterFeature(service, feature)的調(diào)用，samgr也會先生成一個(gè)FeatureImpl對象，再將該對象加入到 g_samgrImpl.services向量中對應(yīng)的service 的ServiceImpl 對象的向量features中去，以完成feature的注冊。這一句看起來比較繞，簡單來說，就是g_samgrImpl的services向量管理著所有登記在冊的services的ServiceImpl ，而每個(gè)ServiceImpl又通過自己的features向量管理自己所有的features。【更具體的實(shí)現(xiàn)過程，后面會有詳細(xì)的代碼分析?！?/p>
在接下來的系統(tǒng)運(yùn)行中，serviceName/serviceID(Sid) 和featureName/featureID(Fid) 都是非常重要的信息，samgr可以通過它們來找到對應(yīng)的ServiceImpl/FeatureImpl對象，并提供相應(yīng)的服務(wù)/功能。
- [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è)登記在g_samgrImpl.services向量里的service創(chuàng)建Queue和TaskPool這些運(yùn)行環(huán)境了，在SAMGR_StartTaskPool() 這一步依次創(chuàng)建和啟動service任務(wù)/線程，線程入口是TaskEntry()函數(shù)，位于Hi3861/foundation/distributedschedule/services/samgr_lite/samgr/source/task_manager.c 文件內(nèi)。
各個(gè)服務(wù)的TaskEntry線程，監(jiān)控著各自的消息隊(duì)列Queue，從中檢出消息，獲取Exchange封裝的數(shù)據(jù)，根據(jù)里面的相關(guān)標(biāo)記調(diào)用相關(guān)的msg handler來進(jìn)行對應(yīng)的處理。
上面的流程僅僅是啟動了用SYS_SERVICE_INIT()和SYS_FEATURE_INIT() 標(biāo)記的service和feature，而通過SYSEX_SERVICE_INIT/APP_SERVICE_INIT/ SYSEX_FEATURE_INIT/APP_FEATURE_INIT 標(biāo)記的service和feature(如在前面提到的示例程序samgr里定義的一部分service和feature)，則會在系統(tǒng)啟動到 BOOT_APP 這一步時(shí)，通過發(fā)送消息BOOT_SYS_COMPLETED到Bootstrap的消息隊(duì)列中，讓Bootstrap調(diào)用MessageHandle()來處理該消息：通過調(diào)用INIT_APP_CALL(service)和INIT_APP_CALL(feature)來完成APP service和Feature的啟動，從而提供用戶定義的服務(wù)和功能。
上面是service/feature的注冊和啟動的大概過程，主要的工作都是samgr來實(shí)現(xiàn)的，這就是samgr_lite組件的基礎(chǔ)代碼部分所提供的功能。
log和簡單的步驟描述，見附件log。
接下來我會對一些重要的結(jié)構(gòu)體進(jìn)行分解，對部分流程進(jìn)行詳細(xì)的分析。
51CTO和華為官方合作共建的鴻蒙技術(shù)社區(qū)
