Changes between Version 1 and Version 2 of Ticket #424


Ignore:
Timestamp:
2013-03-08T08:45:22Z (12 years ago)
Author:
Vojtech Horky
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #424

    • Property Keywords gsoc13 added

  • Ticket #424 – Description

    v1 v2  
    1 In the majority of cases we have converged to using IPC as a means of performing remote procedure calls. We 'trivially' wrap IPC communication into a C API. There is a lot of repetitive effort associated with writing such code, which could be automated.
     1Implement compiler (generator) for the remote procedure calls over the IPC in HelenOS.
    22
    3 We should introduce a simple interface definition language and generate the IPC code from that. An interface definition might consist of:
    4   * interface name
    5   * optionally list of interfaces that we accumulate/extend
    6   * list of methods (calls)
    7   * list of events (callbacks)
     3 Details::
     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.
     13 [[br]][[br]]
     14 The result of the compilation (generation) would be a set of C sources and headers files containing:
     15   * enums declaring method and event codes
     16   * typedefs encapsulating the interface instance for server and client
     17   * method and event ops structures
     18   * method and event dispatcher (switch statement) - on the called side
     19   * method and event call marshalling functions - on the calling side
     20   * method and event call unmarshalling functions - on the called side
     21   * code to set up and tear down the interface (mainly the callback session)
     22 [[br]]
     23 It would be preferable to have the generator written in Python as most of the build tools are implemented in Python.
    824
    9 A method or event declaration shall have:
    10   * a name
    11   * return type
    12   * list of input and output arguments (and their types)
    1325
    14 The allowed types depend on the level of sophistication of the implementation and can range from simple (integer) to more complex (string, struct, array).
     26 What Gains and Benefits will this bring?::
     27 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 greatly adding of new interfaces. In the longer term, it would simplify creating bindings for other languages (e.g. OOP-style generator for C++).
    1528
    16 By compiling an interface definition we would obtain a set of C+header files containing:
    17   * enums declaring method and event codes
    18   * typedefs encapsulating the interface instance for server and client
    19   * method and event ops structures
    20   * method and event dispatcher (switch statement) - on the called side
    21   * method and event call marshalling functions - on the calling side
    22   * method and event call unmarshalling functions - on the called side
    23   * code to set up and tear down the interface (mainly the callback session)
     29 Difficulty::
     30 medium
     31
     32 Required skills::
     33 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.
     34
     35 Documentation::
     36 * [wiki:IPC Introduction to HelenOS IPC]
     37 * [wiki:AsyncSessions IPC sessions in HelenOS]
     38 * [wiki:Tracing Tracing IPC calls]
     39
     40 Possible mentors::
     41 HelenOS Core Team