Base API renovation

[nfeske]

Genode's base API evolved over the years. When we started in 2006, our mindset was very much influenced by L4, which regarded synchronous IPC as the only mechanism needed. We used to implement components ("servers") in a procedural programming style with a fully synchronous control flow within the component and across components (IPC).

We eventually realized that the restriction to synchronous IPC was misguided. See Section 3.6.2. "Asynchronous notifications" in http://genode.org/documentation/genode-foundations-15-05.pdf for a detailed discussion of the problems. When we started to embrace the use of asynchronous notifications and to disregard blocking RPC between components, we found ourselves designing components as state machines rather than procedural programs. To promote this programming style, we introduced the so-called server API (os/server.h). See https://github.com/genodelabs/genode/blob/master/repos/os/src/server/nic_loopback/main.cc for a canonical example of such a component.

We found that this new style greatly increased the robustness and flexibility of the components. In particular, it completely alleviates race conditions, which constantly troubled us in the past. Now, following the new paradigm, we may end up on a deadlock, but such a situation is easy to debug compared to sporadic race conditions. Over the past two years we have redesigned all Genode session interfaces to avoid blocking RPC. The only remains are the parent and root interfaces, which we still need to address.

Still, the Genode API retained compatibility to the old (= wrong) style of developing components. We should finally clean the API from our past mistakes.

Hereby I propose the following changes:

Removal of side effects

Right now, most components rely on the globally available Genode::env() singleton object for interacting with its environment. When calling a function or method, one never knows for sure if the called code interacts with the env. E.g., we can simply create an instance of Timer::Connection. Under the hood, the Connection object accesses the env to open a timer session at the parent. In the spirit of capability-based security, let us drop the global env. Instead, let us pass all materials that are needed by the called code explicitly to the called code (e.g., by passing a reference to a Parent & as argument. This way, someone inspecting the calling code can immediately see the possible reach of the called code. Another prominent example is the latent use of env()->heap(), which allows any code to arbitrary consume memory. Instead, let us pass an Allocator & to the called code. This way, we re-enforce that library code stays clean from the policy where memory is allocated from. If no Allocator & is passed, we know that no dynamic memory allocation is performed. If an Allocator & is required, the called code needs to explain (in the form of its documentation) why the allocator is actually needed. Moreover, by passing an Allocator_guard, the calling code can impose a limit of the memory consumption on the called code.

Granted, the explicit passing of such arguments may lead to slightly more verbose code. But in my opinion, this inconvenience is greatly outweighed by the benefits of alleviating side effects. Furthermore, I think that the inconvenience isn't actually increasing much in practice, thanks to C++11-style member initializers.

Component API

Traditionally, components started their execution at a main function because, well, this is how it's supposed to be, right? The program exits as soon as main returns. With the introduction of the server API (http://genode.org/documentation/release-notes/13.11#New_server_API), I experimented with different approach: The execution of a component starts at a construct function that takes a form of the Genode environment as argument. The function is expected to initialize the component. Upon completion of the initialization, the function returns. Now, the component is ready to respond to incoming RPC requests or signals. Each time such a request/signal comes in, a handler is executed. The handler applies the component-internal state changes and returns immediately. No blocking call is performed. We have essentially a state machine.

Over the past two years, we have applied this new approach to all new components - to a great success. So it is time to promote this API to become Genode's base API. The major benefits are:

• Servers will become easier to develop as the API is much simpler. Previously, a server had to manually create a CAP connection and an RPC entrypoint. Now, each component has an entrypoint.
• Signals and RPC requests are handled in the context of the same thread, which alleviates the need for locking as long as the component is single threaded, which is actually the case for most components.
• The notion of Thread, Signal_receiver, Rpc_entrypoint are no longer needed by the developer of a component. There is simply an Entrypoint, which is able to handle both RPC requests and signals.

Shunning pointers

The Genode API has still a lot of places where pointers are taken as arguments or exposed from objects. We didn't know better when we started with Genode. Now we do. So let us clean up the API in this respect. Just a simple example, right now Heap takes an RM-session pointer and an RAM-session pointer as arguments. These should be references. Pointers should be used only in situation where a nullptr is a reasonable argument, or when dealing with string literals as char const *.

[nfeske]

As a first step, 1ca0676 introduces the Component and Entrypoint interfaces. See the commit message for more information.

[ssumpf]

@nfeske: Please move 639cb88, 20d1ecd, and 3b383c3 to staging.

[nfeske]

The revised API is now in use for more than a year. We can rest the case.