Hello,

if you are interested in getting an insight into the decision of removing the IDL compiler from the user-land tool chain (in both Genode and L4re), you may refer to my study of the subject:

"A Case Study on the Cost and Benefit of Dynamic RPC Marshalling for Low-Level System Components"

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

As far as I know, the integration with Ada would actually be quite straight forward because the class layout of Ada is compatible with C++. This enables you to call virtual C++ functions (the IPC stub code) from Ada code.

Regards Norman

Hi Valery,

Ada is nice, but what if no OOP exist in the language at all, like in plain C? A combination of C with IDL was good enough to use.

So, Genode is using a dynamic IPC marshalling too? But I also see a "Liasis RPC stub-code generator by Stefan Kalkowski" in the Genode wiki, so maybe, a mixed approach can be used too...

Indeed, dynamic RPC marshalling was motivated by and first introduced with Genode (back then called Bastei). On Genode, we use to define each RPC interface using an abstract base class. This class is inherited by two classes 'client' and 'server'. The 'client' class implements the client-side RPC stubs by implementing the abstract interface. The 'server' class implements a server-side 'dispatch' function that calles the abstract functions. The 'server' class is further inherited by a 'component' class that implements the actual server semantics (the functions declared in the abstract RPC interface). This way, interface, marhalling code, and server semantics are well separated. Furthermore, for client code working with the abstract RPC interface class only, it becomes transparent whether it is using a remote or locally implemented service. Liasis meant to automate the task of implementing the 'client' and 'server' classes by parsing the abstract RPC interface and generating the marshalling code. However, we never started using it in practice because we figured that maintaining the 'client' and 'server' stub codes manually is actually not as cumbersome as we expected. ;-)

Is Liasis publically available and ready? or maybe, some other RPC stub generators exist? -- I used Fiasco with DICE and L4env, now L4env and DICE are discontinued. Maybe, other RPC stub generators/IDL compilers, compatible with Fiasco API, exist?

In my opinion, throwing an IDL compiler at the problem of interfacing components in a microkernel-based system is a misconception. I guess the original line of thought for doing this was "A multi-server OS is some kind of distributed system, isn't it? What do the distributed-systems guys use to communicate? CORBA, IDL? It works for them, so it should work for us, too." However, this argument discards the fact that communication partners in a microkernel-based system operate on an entirely different abstraction level. The interfaces of such components are as low-level as the system-call interface of a monolithic kernel because those components address very similar concerns. No one argues that such a system-call interface is tied to one particular systems language. It is just common sense to use one particular language (mostly C) for this purpose. When going to up to application level, there are established frameworks for inter-component interaction that could be used in a microkernel-based system via an additional level of abstraction (e.g., virtual network interfaces).

In retrospect I consider the decision of taking the IDL compiler out of the loop as a big success for Genode. It boosted our productivity by a wide margin and eliminated a source of constant trouble.

Cheers Norman

Hi;

On Thu Feb 24, 2011 at 13:49:09 +1200, Valery V. Sedletski wrote:

On Tue, 22 Feb 2011 11:52:11 +0100, Bj rn D bel wrote:

...

...

Is DICE discontinued? And how can I do something with communication code if not using IDL?

Yes, Dice has been discontinued and is no longer supported in L4Re.

For the moment, you can use the C++ IPC streams provided by L4Re for communication. You can also directly use the C system call bindings for IPC, which requires you to write the marshalling/unmarshalling code manually, though.

Yes, of course, I knew of such a possibility. I can manually call IPC syscall of L4, but here is so much handwork and so it is not desirable.

...

For other programming languages it would for now be necessary to provide some kind of bindings to the C or C++ interfaces. Difficulty varies depending on the language. We're using Lua for configuration purposes and it's easy to call C functions from Lua code.

I just prefer using C+IDL than C++ because I believe that OOP must be a property of an OS but not a single language, like an approach in IBM's SOM/DSOM. In SOM, applications can be written on any language with IDL bindings, and class hierarchy can use a cross-language inheritance (classes are encapsulated, so you doesn't have to have a class source for using it, and you can use a C++ class from a a C program and inherit a C-written class from a C++-written one).

I think, hiding the IPC under C++ iostreams is an interesting approach, but with my point of view, not good because it ties a programmer to a single language. (But maybe, someone will make the bindings for C somehow?)

The approach 'forces' you to write the actual (un)marshalling code in C++ but nobody prevents you from doing:

extern "C" int some_func(int some_int, char some_char) { Ipcstream x(); x << some_int << some_char; return x.ipc(...); }

Then you can call some_func from basically everywhere, including other languages. We use that to have a C interface for L4Re. Of course this is a bit more work because you need to implement both sides, add a header file etc. which an IDL compiler would do for you. But experience shows that this approach is acceptable although an IDL compiler would still be nice to have.

Adam