| 4 | | |
| 5 | | |
| 6 | | |
| 7 | | |
| 8 | | |
| 9 | | |
| 10 | | |
| 11 | | |
| 12 | | |
| 13 | | |
| 14 | | |
| | 4 | IPC is almost everywhere in HelenOS and most of the time it looks as a remote procedure call (RPC). However, the wrapping code is written by hand although most of it merely wraps IPC calls and error handling. Writing this wrapper code can be quite easily automated to reduce the amount of repetitive code. |
| | 5 | [[br]][[br]] |
| | 6 | The task is to create an interface definition language (IDL) and a generator that would create the respective C code to execute the RPC. |
| | 7 | [[br]][[br]] |
| | 8 | The IDL would define interfaces where each interface would have its unique name, optionally list of parent interfaces (that are extended) and a list of methods (calls) and events (callbacks). Each method and event has its name, return type and list of input and output arguments together with their types. |
| | 9 | [[br]][[br]] |
| | 10 | The IPC in HelenOS is mostly asynchronous and thus the concept of calls and callbacks is necessary. However, the implementation shall not provide only the naive implementation of classical callbacks but also the concept of futures (promises) to allow writing the servers in the same pseudo-synchronous manner as it is today. |
| | 11 | [[br]][[br]] |
| | 12 | In the first iteration, the IDL can support only basic types (plain integers and blocks of memory would be sufficient for majority of the interfaces), features such as structures or arrays can be added later. |
| | 13 | [[br]][[br]] |
| | 14 | The result of the compilation (generation) would be a set of C sources and headers files containing: |
