Solution outline

As a first step in the design of the microkernel, we tried to reduce the functionality of the $\mu$-kernel to a bare minimum, yet allowing a reasonable implementation of the necessary servers. We concluded that the necessary system calls can be grouped as follows:

Task and thread management. These system calls cover the loading and unloading of tasks into the system, and the creation, destruction and running of threads. They also permit the binding of a hardware interrupt to an interrupt-handling thread.

Memory management. These system calls handle the sharing of memory between tasks. This subsystem should also provide an abstraction of the paging mechanism (this was considered in the design of the microkernel, but has not been implemented yet).

Message passing. The kernel provides an asynchronous messaging system, in the form of a set of ports assigned to each task. Each port functions as a mailbox where fixed-sized messages from other tasks are received. These system calls cover the creation, deletion and management of ports.

These system calls provide a simple processor abstraction, and they were sufficient for the implementation of all the basic servers. They are also completely policy-independent (note that there isn't even a simple scheduler within the microkernel: just the thread abstraction). Tasks, message queues, shared memory objects and threads have permission data that allows the operating system to restrict the way in which they interact with user programs. The microkernel implements software protection rings that may be used by the operating system to secure it's architecture. Also, a clear interface between the architecture-neutral, algorithmic section of the kernel (where all the permissions, shared memory objects, message queues, etc. are maintained) and the hardware-specific section is defined (a similar approach is described in [3]).