Following with our SysLink saga, now we will dive into its internals.
As we stated before, SysLink is a software stack which implements an Inter-Processors Communication (IPC), whose the purpose is enabling the Asymmetric Muli-Processing (AMP).
Most of the readers are more familiar with the concept of the Symmetric Multi-Processing (SMP), which is the most common approach to handle multiple processors in a computer, where a single operating system controls and spreads the processing load among the available processors. Typically these processors are identical.
On the contrary, AMP is designed to deal with different kind of processors, each one running different instances of operative systems, with different architectures and interfaces. The typical approach is to have a master processor with one or more slave units, all of them sharing the same memory area, hence the operating system running in the master processor expose the other processors as other devices available in the system (figure 1).
The main advantage of AMP, as we mention in the previous post, is that we can integrate specialized processors and delegate them tasks that are rather expensive to execute in our general purpose processor, such as multimedia, cryptography, real-time processing, etc.
All the operating systems, executed in an AMP system, must share, at least, one key component: a mechanism of Inter-Processors Communication, because with it, they will be able to interchange data and synchronize tasks among each other.
Basically there are two types of IPC: shared memory and message passing. With the shared memory we avoid copying the data to process in other unit, but also we will demand complicated semaphoring protocols, in order to avoid overlapping, what lead to the data corruption. On the other hand, message passing is oriented to the transfer of small chunks of data, called messages, sent by one processor and received by another, and are used to notify, to control and synchronize.
Therefore, SysLink version 2.0, provides a set of components for IPC, for both shared memory and message passing (figure 2):
- MultiProc: identifies and names each available processor in the configuration.
- SharedRegion: handles memory areas which will be shared across the different processors.
- Gate: provides local and remote context protection, preventing preemption by another thread locally and protects memory regions from remote processors.
- Message: supports the variable length message passing across processors.
- Notify: registers callback what will be executed when a remote event is triggered.
- HeapBuf: manages fixed size buffers that can be used by multiple processors within the shared memory.
- HeapMem: manages variable size buffers that can be used by multiple processors within the shared memory.
- List: provides a way to create, access and manipulate double linked list in a the shared memory.
- NameServer: a dictionary table within the shared memory.
All these operations are done through ioctl operations to the /dev/syslink_ipc device.
Nonetheless, SysLink v2.0, being a master/slave configuration, it must provide a way to control the slave processors, operations like starting and stopping, to load an operative system into them, and so on. In that regard, there is a module called the Processor Manager, which is operated also through ioctl calls to the /dev/syslink-procmgr device, and also to the specific processors, what are also mapped to the device file-system as /dev/omap-rproc[0-9], in the case of the OMAP processors.
Now, on top of all these IPC facilities, there must be a façade for all the remote operation that we could execute, and that façade is called Remote Command Messaging (RCM). Our application, which is running in the master processor, will act as client RCM and will request remote commands on the RCM server, which is running in a slave processor. DCE (Distributed Codec Engine) is an open source RCM, developed by Rob Clark, to expose distributed multimedia processing in the OMAP4.
And I continue developing a thin API for SysLink 2.0 🙂