Fork us on GitHub Follow us on Google+ Follow us on Facebook Follow us on Twitter

Changes between Version 3 and Version 5 of Ticket #424


Ignore:
Timestamp:
2013-03-28T17:56:23Z (5 years ago)
Author:
Martin Decky
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #424

    • Property Component changed from helenos/unspecified to helenos-infrastructure
  • Ticket #424 – Description

    v3 v5  
    22
    33 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 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:
     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:
    1515   * enums declaring method and event codes
    1616   * typedefs encapsulating the interface instance for server and client
     
    2020   * method and event call unmarshalling functions - on the called side
    2121   * 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.
    24 
     22  [[br]]
     23  It would be preferable to have the generator written in Python as most of the build tools are implemented in Python.
    2524
    2625 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 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++).
     26  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++).
    2827
    2928 Difficulty::
    30  medium
     29  Medium
    3130
    3231 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.
     32  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.
    3433
    3534 Documentation::
     
    3938
    4039 Possible mentors::
    41  HelenOS Core Team
     40  HelenOS Core Team, Martin Decky, Jiri Svoboda