...

Two applications connected to a same instance of IARM-Bus are able to exchange events or RPC calls. On a typical system, only one instance of IARM-Bus instance is needed. If desired, it is possible to have multiple IARM-Bus instances. However, applications connected to different buses will not be able to communicate with each other.

Bus Daemon

Each Bus Instance is managed by a single Bus Daemon Process. The Bus Daemon oversees the activities on the bus and manage common resources competed by all connected applications. Applications requesting a shared resource must firstly acquire from the Bus Daemon. Once it is done with the resource, it must release the ownership back to Bus Daemon so that other applications can use the resource. The IARM Bus Daemon offers standard APIs to request and release ownership of a resource. In Essence, a Bus Daemon itself is a regular applications connected to the IARM-Bus with special privileges. It is the only entity that has knowledge of all applications connected to the bus, and has the authority of granting or denying resources.

...

Since all the events published by the application are tied to its well-known name, the application must make its well-known name available to other applications that wish to use its service. The well-known name can be thought of as the Namespace within which the application's events and RPC methods live. This name must be declared in the application's public header file. In our example, this file is irMgr.h

 #define IARM_BUS_IRMGR_NAME "IRMgr"

...

 Naming 

...

Convention: IARM_BUS_<Manager>_NAME "Manager"

When the application initialize with IARM-Bus, it provides its well-known name:

...

IARM_Bus_Init(IARM_BUS_IRMGR_NAME);

...

IARM_Bus_Connect();

...

Applications should use the defined macro of the owner's well-known name (IARM_BUS_IRMGR_NAME in this example) when sending or listening for events.

...

• Follow the naming conventions recommended.
• Register to IARM-Bus with its well-known name during initialization.

...

IARM_Result_t IARM_Bus_Init(const char name);

...

IARM_Result_t IARM_Bus_Connect(void);

• Declare its event enumerations and event data types in public header file.
• Register all its events during initialization using _EVENT_MAX:

...

IARM_Result_t IARM_Bus_RegisterEvent(IARM_EventId_t maxEventId);

• Send/Broadcast Events:

...

IARM_Result_t IARM_Bus_BroadcastEvent(const char *ownerName, IARM_EventId_t eventId, void *data, size_t len);

...

 If an application wants to receive and handle events , it needs to :

• Register to IARM-Bus with its well-known name during initialization.

...

IARM_Result_t IARM_Bus_Init(const char *name);

...

        IARM_Result_t IARM_Bus_Connect(void);

• Register event handler :

...

 IARM_Result_t IARM_Bus_RegisterEventHandler(const char *ownerName, IARM_EventId_t eventId, IARM_EventHandler_t handler);

• Implement the handler.

How to Create and Invoke RPC Methods

...

Since all the RPC methods published by the application are tied to its well-known name, the application must make its well-known name available to other applications that wish to use its service. The well-known name can be thought of as the Namespace within which the application's events and RPC methods live. This name must be declared in the application's public header file. In our example, this file is irMgr.h

 #define IARM_BUS_IRMGR_NAME "IRMgr"

...

Naming Convention: IARM_BUS_<Manager>_NAME "Manager"

 When the application initialize with IARM-Bus, it provides its well-known name:

 IARM_Bus_Init(IARM_BUS_IRMGR_NAME);

...

IARM_Bus_Connect();

...

 Applications should use macro of the well-known name (IARM_BUS_IRMGR_NAME in this example) when invoking the RPC method.

...

IRMgr_SetRepeatInterval(int newInterval) 
 {
     IARM_Bus_IRMgr_SetRepeatInterval_Param_t param;
     param. timeoutNewValue = 200;
     IARM_Bus_Call (
         IARM_BUS_IRMGR_NAME, /* Owner of the Method */
         IARM_BUS_IRMGR_API_SetRepeatInterval,/* Name of Method */
         (void *)&param, / Parameter of Method */
         sizeof(param)); /* Length of the Parameter */ 
     )
 }

...

In

...

the

...

IR

...

Manager's

...

implementation

...

of

...

RPC

...

Method,

...

we

...

have

...

already

...

learned

...

from

...

previous

...

sections

...

that

...

this

...

RPC

...

method

...

is

...

registered

...

with.

IARM_Result_t IARM_Bus_RegisterCall(
     _BUS_IRMGR_API_SetRepeatInterval,  /* RPC Method Name */
     _SetRepeatInterval			/* RPC Method Implementation*/ 
 )
Where _SetRepeatInterval changes the actual settings.
 static IARM_Result_t _SetRepeatInterval(void *arg)
 {
     /* First cast the argument to its target type */
     IARM_Bus_IRMgr_SetRepeatInterval_Param_t 
     *param = (IARM_Bus_IRMgr_SetRepeatInterval_Param_t *)arg;
     /* changes actual settings here */
 } 

...

The application can then choose which implementation to link to at build time based on its needs. To use the multi-app version of API, the application links to libirMgrCli.so. To use the single-app version of the API, the application links to libirMgr.so. In either choice, the application is no longer coupled to IARM. The following diagrams demonstrate the linkage relationship between applications and the generic API.

Porting layer of IARM-Bus

...

 To know more about SoC/Application level APIs details use in RDK, refer the link  IARM BUS API Documentation