dynrpc Code Complexity

A basic marshalling infrastructure for L4 version 2 IPC of the dynrpc framework is 357 lines of C++ code. I wrote a similar infrastructure for Linux network sockets in about an hour and it had a size of 445 lines of C++ code. This framework is almost negligible when compared to Dice.

I also compared the size of the accompanying client and server files for the test scenarios that I used to measure stub performance. These were 1772 lines of code for the client side and 2115 lines of code for the server. Additionally some 240 lines of code in common used header files were required, which totals the dynrpc test scenario to 4127 lines of code.

The message packing and unpacking has to be written by hand, which can lead to errors in the order of arguments in the message buffer. Also, the whole server loop and dispatcher has to be written by hand, which is a tedious task, since most server loops and dispatchers are the same. A server loop has 85 lines of code in average, the smallest (for one function) 38 lines of code, and the bigger ones adding approximately 13 lines for each additional function.

I compared this to the size of the test case for the Dice generated stubs. The client side code was 1272 lines of code; the server side required 1194 lines of code, no common header files but an IDL file of 363 lines of code. This sums up to 2829 lines of code, which is 1298 lines less than the dynrpc test, or 50% less to contain possible errors.

As I mentioned before, dynrpc can only be used with C++, whereas Dice supports C as well. Also, dynrpc relies on the C++ template libraries as trusted computing base.

6.5

Summary

In this chapter I showed that the optimizing IDL compiler I wrote performs better than non-optimizing and on par with other optimizing IDL compilers. I also showed, that its design is flexible and allows to add support for new features. This extensible design also allows implementing new optimization strategies, such as default timeout, easily.

With respect to code complexity, Dice is about the same size or smaller than other stub code generators for L4. It is bigger than alternative approaches, such as dynrpc, but also richer in functionality and flexibility.

Chapter 7

Conclusion and Outlook

This chapter provides a summary of my contributions and an outlook on possible exten- sions of this work.

7.1

Contributions

Communication in microkernel-based operating systems has many different forms. It is used to signal state, propagate rights, and for RPCs. Because components in a microkernel-based system often run in their own protection domains, inter-component communication involves crossing these protection boundaries and requires marshalling and unmarshalling of messages. With fast communication mechanisms to switch be- tween protection domains, the stubs that setup, send, and receive messages make up a large portion of the communication. Stub code generators can be used to generate the communication code automatically from a small description of the communication interface. I addressed three concrete challenges for communication code generation in microkernel-based operating systems.

Forms of Communication

In Chapter3I showed that communication in microkernel-based systems is not only used to call components in other protection domains, but also to signal state changes, send one-way messages, or transfer rights to resources. When using a stub code generator, non-RPC forms of communication have to be supported. I discussed how each of the named forms of communication can be represented in an IDL and that the IDL compiler can generate well-performing code from it. This included the ability to use a generic communication framework, yet still exploit platform specific mechanisms.

In the Evaluation Chapter I demonstrated that the generated stubs also performed as good as or within close range of hand-written code and other stub code generators. These results show that a tool can be used to generate high-performance stubs.

Platform Independence

In Chapter 4 I explored how platform independence can be provided with an IDL but still platform specific optimizations can be exploited using attributes. I gave examples for using L4 specific communication mechanisms, such as indirect parts, or the transfer of flexpages. I also discussed optimization strategies for communication in generated stubs, such as parameter reordering or copy avoidance.

The platform independence allows using the same description of a component inter- face to generate communication code for different platforms. In the Evaluation Chapter I was able to give examples for this platform independence.

Feature Integration

Chapter 5 shows how existing designs for interface definition languages and their com- pilers can be integrated into an IDL compiler for microkernel-based operating systems. I discuss new extensions to the IDL to allow support of platform specific features, such as flexpages and indirect parts. I gave explicit examples for these different programming environments, such as resource accounting or resource reservation and how these can be supported in an stub code generator. I also discussed how real-time applications can use generated stubs and still maintain their timing guarantees.

Evaluation

In Chapter 6 I showed that the optimizing IDL compiler I wrote performs better than non-optimizing and on par with other optimizing IDL compilers. I also showed that its design is flexible and allows adding support for new features. This extensible design also allows implementing new optimization strategies, such as default timeout, easily.

With respect to code complexity, Dice is about the same size or smaller than other stub code generators for L4. It is bigger than alternative approaches, such as dynrpc, but also richer in functionality and flexibility and requires much less hand-written code.