diff --git a/README.md b/README.md index b253c083d7751e3464b32856345b0a35e92beae3..e6ffd48d4f69bf9310ebde045ab381e0f1ecf47d 100644 --- a/README.md +++ b/README.md @@ -1,121 +1,65 @@ -# samgr\_lite +# samgr_lite -- [Introduction](#section11660541593) -- [Directory Structure](#section1464106163817) -- [Constraints](#section1718733212019) -- [Developing a Service](#section159991817144514) -- [Developing a Feature of a Service](#section11510542164514) -- [Developing an External API for Intra-Process Communication](#section1685211117463) -- [Invoking a Service in the Same Process](#section3690162916462) -- [Developing an External API for IPC](#section9220246194615) -- [Invoking a Service in Another Process](#section114372711475) -- [Developing a Client Proxy for Inter-Process Service Invocation](#section09341923114710) -- [Repositories Involved](#section10365113863719) +## Introduction -## Introduction +Due to limited platform resources, a unified system ability framework is provided to harmonize differences of hardware architectures (for example, RISC-V, Cortex-M, and Cortex-A), platform resources, and running modes. Two types of hardware platforms (M- and A-core) are defined. -Due to limited platform resources, a unified system ability \(SA\) framework is provided to harmonize differences of hardware architectures \(for example, RISC-V, Cortex-M, and Cortex-A\), resources, and running modes. Two types of hardware platforms \(M- and A-core\) are defined. +- M-core: hardware platforms with Cortex-M or equivalent processing capabilities. The system memory is generally less than 512 KB. There is only a lightweight file system that can be used in limited scenarios, or no file system at all. M-core platforms comply with the Cortex Microcontroller Software Interface Standard (CMSIS). +- A-core: hardware platforms with Cortex-A or equivalent processing capabilities. The system memory is greater than 512 KB. There is a comprehensive file system for storing a large amount of data. A-core platforms comply with the Portable Operating System Interface (POSIX) specifications. -- M-core: hardware platforms with Cortex-M or equivalent processing capabilities. The system memory is generally less than 512 KB. There is only a lightweight file system that can be used in limited scenarios, or no file system at all. M-core platforms comply with the Cortex Microcontroller Software Interface Standard \(CMSIS\). -- A-core: hardware platforms with Cortex-A or equivalent processing capabilities. The system memory is greater than 512 KB. There is a comprehensive file system for storing a large amount of data. A-core platforms comply with the Portable Operating System Interface \(POSIX\) specifications. - -This service-oriented SA framework enables you to develop services, features, and external APIs, and implement multi-service process sharing and service invoking for inter-process communication \(IPC\). Wherein: +This service-oriented system ability framework enables you to develop services, features, and external APIs, and implement multi-service process sharing and service invoking for inter-process communication (IPC). Where: - M core provides services, features, external APIs, and multi-service process sharing development. - In addition to the capabilities provided by M-core, A-core provides capabilities such as IPC service invoking, permission control for IPC service invoking, and IPC service API development. -Service-oriented architecture +## System Architecture + +Figure 1 Service-oriented architecture + ![](figures/en-us_image_0000001128146921.png) -- Provider: a service provider that provides capabilities \(external APIs\) for the system -- Consumer: a service consumer that invokes the features \(external APIs\) provided by the service -- Samgr: an agency that manages capabilities provided by providers and helps consumers discover providers' capabilities +- Provider: a service provider that provides capabilities (external APIs) for the system. +- Consumer: a service consumer that invokes the features (external APIs) provided by the service. +- Samgr: an agency that manages capabilities provided by providers and helps consumers discover providers' capabilities. -Main objects of the SA framework: +**Figure 2** Main objects of the system ability framework ![](figures/en-us_image_0000001081285004.png) - SamgrLite: provides service registration and discovery. - Service: implements lifecycle APIs of the service during service development. - Feature: implements lifecycle APIs of the feature during feature development. -- IUnknown: implements external APIs for services or features based on **IUnknown**. +- IUnknown: implements external APIs for services or features based on **IUnknown**. - IClientProxy: implements the consumer's proxy to send messages during IPC invoking. - IServerProxy: implements the provider's proxy during IPC invoking, which needs to be implemented by developers. -## Directory Structure - -**Table 1** Structure of the source code directory of the SA framework - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Directory

-

Description

-

interfaces/kits/samgr_lite/samgr

-

External APIs of the M- and A-core SA frameworks

-

interfaces/kits/samgr_lite/registry

-

External APIs for service invocation between A-core processes

-

interfaces/kits/samgr_lite/communication/broadcast

-

External APIs of the event broadcast service within M- and A-core processes

-

services/samgr_lite/samgr/adapter

-

POSIX and CMSIS interface adaptation layer, which is used to harmonize the differences between the APIs of M- and A-core

-

services/samgr_lite/samgr/registry

-

Stub functions for M-core service registration and discovery

-

services/samgr_lite/samgr/source

-

Basic code for the M- and A-core SA frameworks

-

services/samgr_lite/samgr_client

-

Registration and discovery for service invocation between A-core processes

-

services/samgr_lite/samgr_server

-

IPC address management and access control for service invocation between A-core processes

-

services/samgr_lite/samgr_endpoint

-

Packet RX/TX management for A-core IPC

-

services/samgr_lite/communication/broadcast

-

Event broadcast service for M- and A-core processes

-
- -## Constraints - -- The SA framework is developed using the C programming language. -- Services in the same process use **IUnknown** for invoking. Messages are passed to the service through **IUnknown**. -- The service name and feature name must be constant character strings and the length must be less than 16 bytes. -- More-core depends on the Bootstrap service and calls the **OHOS\_SystemInit\(\)** function in the system startup function. -- A-core depends on the Samgr library and calls the **SAMGR\_Bootstrap\(\)** function in the **main** function. - -## Developing a Service +## Directory Structure + +**Figure 1** Structure of the source code directory of the system ability framework + +| Name | Description | +| -------------------------------------------------- | -------------------------------------------- | +| interfaces/kits/samgr_lite/samgr | External APIs of the M- and A-core system ability frameworks. | +| interfaces/kits/samgr_lite/registry | External APIs for service invocation between A-core processes. | +| interfaces/kits/samgr_lite/communication/broadcast | External APIs of the event broadcast service within M- and A-core processes. | +| services/samgr_lite/samgr/adapter | POSIX and CMSIS interface adaptation layer, which is used to harmonize the differences between the APIs of M- and A-core.| +| services/samgr_lite/samgr/registry | Stub functions for M-core service registration and discovery. | +| services/samgr_lite/samgr/source | Basic code for the M- and A-core system ability frameworks. | +| services/samgr_lite/samgr_client | Registration and discovery for service invocation between A-core processes. | +| services/samgr_lite/samgr_server | IPC address management and access control for service invocation between A-core processes. | +| services/samgr_lite/samgr_endpoint | Packet Rx/Tx management for A-core IPC. | +| services/samgr_lite/communication/broadcast | Event broadcast service for M- and A-core processes. | + +## Constraints + +- The system ability framework is developed using the C programming language. +- Services in the same process use **IUnknown** for invoking. Messages are passed to the service through **IUnknown**. +- The service name and feature name must be constant strings and the length must be less than 16 bytes. +- More-core depends on the Bootstrap service and calls the **OHOS_SystemInit()** function in the system startup function. +- A-core depends on the Samgr library and calls the **SAMGR_Bootstrap()** function in the **main** function. + +## Developing a Service - Inherit and redefine a service. @@ -194,7 +138,7 @@ Main objects of the SA framework: ``` -## Developing a Feature of a Service +## Developing a Feature of a Service - Inherit and redefine a feature. @@ -286,9 +230,9 @@ Main objects of the SA framework: ``` -## Developing an External API for Intra-Process Communication +## Developing an External API for Intra-Process Communication -- Define the **IUnknown** API. +- Define the **IUnknown** API. ``` typedef struct DemoApi { @@ -300,7 +244,7 @@ Main objects of the SA framework: } DemoApi; ``` -- Define the reference object of **IUnknown**. +- Define the reference object of **IUnknown**. ``` typedef struct DemoRefApi { @@ -308,7 +252,7 @@ Main objects of the SA framework: } DemoRefApi; ``` -- Initialize the object of **IUnknown**. +- Initialize the object of **IUnknown**. ``` static DemoRefApi api = { @@ -329,7 +273,7 @@ Main objects of the SA framework: ``` -## Invoking a Service in the Same Process +## Invoking a Service in the Same Process - Obtain the external API of the service. @@ -362,9 +306,9 @@ Main objects of the SA framework: ``` -## Developing an External API for IPC +## Developing an External API for IPC -- Inherit **IServerProxy** to replace **IUnknown**: INHERIT\_SERVER\_IPROXY +- Inherit **IServerProxy** to replace **IUnknown**: INHERIT\_SERVER\_IPROXY ``` typedef struct DemoFeatureApi { @@ -376,7 +320,7 @@ Main objects of the SA framework: } DemoFeatureApi; ``` -- Initialize the **IServerProxy** object. +- Initialize the **IServerProxy** object. ``` static DemoFeature g_example = { @@ -390,7 +334,7 @@ Main objects of the SA framework: }; ``` -- Implement the **Invoke** function to process IPC messages. +- Implement the **Invoke** function to process IPC messages. ``` static int32 Invoke(IServerProxy *iProxy, int funcId, void *origin, IpcIo *req, IpcIo *reply) @@ -437,7 +381,7 @@ Main objects of the SA framework: ``` -## Invoking a Service in Another Process +## Invoking a Service in Another Process - Obtain the external API of the service in another process. @@ -469,7 +413,7 @@ Main objects of the SA framework: ``` -## Developing a Client Proxy for Inter-Process Service Invocation +## Developing a Client Proxy for Inter-Process Service Invocation - Define a client proxy for the IPC API. @@ -625,9 +569,9 @@ Main objects of the SA framework: ``` -## Repositories Involved +## Repositories Involved -System Ability Management Subsystem +Samgr [**systemabilitymgr\_samgr\_lite**](https://gitee.com/openharmony/systemabilitymgr_samgr_lite) @@ -636,4 +580,3 @@ System Ability Management Subsystem [systemabilitymgr\_safwk](https://gitee.com/openharmony/systemabilitymgr_safwk) [systemabilitymgr\_safwk\_lite](https://gitee.com/openharmony/systemabilitymgr_safwk_lite) -