Follow us on Google+ Follow us on Facebook Follow us on Twitter

Opened 5 years ago

Last modified 12 months ago

#424 new enhancement

RPC/IPC generator

Reported by: Jiri Svoboda Owned by:
Priority: major Milestone:
Component: helenos-infrastructure Version: mainline
Keywords: gsoc13, gsoc14, gsoc15, socis15, gsoc16, gsoc17 Cc:
Blocker for: Depends on:
See also:

Description (last modified by Martin Decky)

Implement compiler (generator) for the remote procedure calls over the IPC in HelenOS.

Details
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.

The task is to create an interface definition language (IDL) and a generator that would create the respective C code to execute the RPC.

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.

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.

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.

The result of the compilation (generation) would be a set of C sources and headers files containing:
  • enums declaring method and event codes
  • typedefs encapsulating the interface instance for server and client
  • method and event ops structures
  • method and event dispatcher (switch statement) - on the called side
  • method and event call marshalling functions - on the calling side
  • method and event call unmarshalling functions - on the called side
  • code to set up and tear down the interface (mainly the callback session)

It would be preferable to have the generator written in Python as most of the build tools are implemented in Python.
What Gains and Benefits will this bring?
There should be no impact at all to the functionality of HelenOS as an operating system. The benefit would be in making the code more readable because a lot of similar code would be removed, being replaced by an automatically generated one. The presence of such generator would also simplify the process of adding a new interfaces. In the longer term, it would simplify creating bindings for other languages (e.g. OOP-style generator for C++).
Difficulty
Medium
Required skills
A successful applicant will have good skills of programming in the C and Python languages and the ability to survive in a non-standard non-POSIX application environment. Knowledge of similar tools (e.g. IDL compiler for CORBA) would be beneficial.
Documentation
Possible mentors
HelenOS Core Team, Martin Decky, Jiri Svoboda

Change History (10)

comment:1 Changed 5 years ago by Jiri Svoboda

Description: modified (diff)

comment:2 Changed 4 years ago by Vojtech Horky

Description: modified (diff)
Keywords: gsoc13 added

comment:3 Changed 4 years ago by Vojtech Horky

Description: modified (diff)

comment:4 Changed 4 years ago by Martin Decky

Component: helenos/unspecifiedhelenos-infrastructure

comment:5 Changed 4 years ago by Martin Decky

Description: modified (diff)

comment:6 Changed 3 years ago by Vojtech Horky

Keywords: gsoc14 added

comment:7 Changed 2 years ago by Jakub Jermář

Keywords: gsoc15 added

comment:8 Changed 2 years ago by Martin Decky

Keywords: socis15 added

comment:9 Changed 18 months ago by Jakub Jermář

Keywords: gsoc16 added

comment:10 Changed 12 months ago by Jakub Jermář

Here is an interesting piece from the Genode project, which basically speaks against using an IDL in favour of dynamic RPC marshalling:

http://genode-labs.com/publications/dynrpc-2007.pdf

Note: See TracTickets for help on using tickets.