VMAC Study
时间：2009-07-06 来源：klutercoco
1.
The following diagram illustrates the library layers, and layer interdependency of a typical VMAC compliant application.
500)this.width=500;" border=0>
2. Core Components
Inter Task Message Manager(IMM) is provided in the form of a Verix/Verix V executable. The IMM is responsible for routing events between co-operating tasks. The IMM updates the default.INI file with the entries of the tasks in the individual IMM*.INI in each GID and starts all the tasks registered in the default .INI file. This task is transparent to all the tasks and the EESL layer works closely with IMM in passing events between tasks providing appropriate abstraction and encapsulation. This task runs in the background and is the core of VMAC architecture. The IMM provides mechanisms for inter task communication (using pipes of the Verix/Verix V OS).
Applications and other tasks to be invoked during a cold power up, must register
with IMM (using the API provided in EESL). IMM is responsible for invoking all the
tasks and other VMAC components, for example, the Device Manager and FrontEnd. Extended Event Services Layer(EESL) is provided as a part of ACT and VMAC libraries and is linked with every executable running in the Multi Application Environment. This layer provides
an API for a task to register with VMAC. This layer allows sending the tasks custom defined events (extended events) between tasks. The library is a layer above the OS that handles the set of extended events. This layer is called the EESL (Extended Event Service Layer). The communication of the extended events is dependent on the IMM utility which is a platform for intertask communication. The extended event functionality embeds events in IMM messages.
This layer provides APIs for sending, receiving events and data associated with it. The following diagram illustrates the interaction of the VMAC component set with
other Verix/Verix V applications. 500)this.width=500;" border=0> Device Manager is provided as a Verix/Verix V executable. This task is responsible for the allocation and de-allocation of devices assigned to the tasks running in the multi-application environment (for use with all VMAC compliant applications). All VMAC compliant tasks request ownership of the devices they require by sending
a request to the Device Manager in the form of a custom event. If all the required
devices are available, they are allocated to the application. The application is
responsible for returning devices to the Device Manager after processing completes. 3. Flow of Custom Events 500)this.width=500;" border=0> 4. EESL APIs:
Applications and other tasks to be invoked during a cold power up, must register
with IMM (using the API provided in EESL). IMM is responsible for invoking all the
tasks and other VMAC components, for example, the Device Manager and FrontEnd. Extended Event Services Layer(EESL) is provided as a part of ACT and VMAC libraries and is linked with every executable running in the Multi Application Environment. This layer provides
an API for a task to register with VMAC. This layer allows sending the tasks custom defined events (extended events) between tasks. The library is a layer above the OS that handles the set of extended events. This layer is called the EESL (Extended Event Service Layer). The communication of the extended events is dependent on the IMM utility which is a platform for intertask communication. The extended event functionality embeds events in IMM messages.
This layer provides APIs for sending, receiving events and data associated with it. The following diagram illustrates the interaction of the VMAC component set with
other Verix/Verix V applications. 500)this.width=500;" border=0> Device Manager is provided as a Verix/Verix V executable. This task is responsible for the allocation and de-allocation of devices assigned to the tasks running in the multi-application environment (for use with all VMAC compliant applications). All VMAC compliant tasks request ownership of the devices they require by sending
a request to the Device Manager in the form of a custom event. If all the required
devices are available, they are allocated to the application. The application is
responsible for returning devices to the Device Manager after processing completes. 3. Flow of Custom Events 500)this.width=500;" border=0> 4. EESL APIs:
相关阅读 更多 +
排行榜 更多 +
