Introduction

The idea behind a microkernel-based operating system is to reduce the size and complexity of the kernel by implementing most of the operating system's functionality in the form of servers that run in user-mode. Initially, this idea promised a dramatic increase in flexibility, safety and modularity.

In a monolithic kernel, the operating system's functions are packed in the kernel: scheduling, memory management, file systems, networking, device drivers, and everything else. Traditionally, the $\mu$-kernel approach only requires scheduling, inter-process communication and the implementation of support for several address spaces to be implemented in the kernel. This suffices to allow the implementation of the rest of the subsystems as servers. The advantages of this approach may be summarized as follows:

1. Different application programming interfaces (APIs) or even OS personalities can coexist in one system.
2. The system becomes more flexible and extensible.
3. Server (and driver) malfunctions are isolated as normal application's are.
4. A smaller kernel is easier to maintain and in general less error-prone.
5. The trusted computing base is significantly reduced.

However, first-generation $\mu$-kernels turned out to be rather inefficient (compared to monolithic kernels), and they lacked real flexibility. Usually, they had rather large system-call sets and were designed to preserve unix-compatibility, but also allowing the construction of novel features. It was a common belief at that time that the layer of abstraction presented by $\mu$-kernels was either too low or too high.

Recent second-generation $\mu$-kernels address the flexibility and efficiency problems that appeared in earlier ones (a survey of this process is presented in [2]). QNX, L4 and the MIT's Exokernel are examples of second-generation microkernels. They were usually designed from scratch, and have smaller system-call sets than their predecessors. Also, to improve the efficiency of the system, they are usually highly dependent on the underlying hardware architecture.

While Sartoris is similar in some aspects to the microkernels just described (i.e. it makes heavy use of inter-process communication mechanisms, uses the task-thread abstraction to present the processor resource to the rest of the system, supports different program privilege levels and allows the execution of I$/$O operations outside the kernel), it provides a simpler abstraction of the processor and memory resources than most of them. Firstly, Sartoris performs no I$/$O at all¹, except for the initial loading of the main system servers. Secondly, since under Sartoris the scheduling is performed by one or more scheduler threads (usually bound to the timer interrupt), all the functions provided by the $\mu$-kernel are non-blocking (blocking is performed at a higher level, usually in the process-server). While these choices didn't yield a particularly small system call set², the nature of the resulting kernel is simple and elegant. Functionally, Sartoris behavior is somehow close to the MIT's Exokernel (further described in [4]), which also attempts to separate protection and management issues, leaving the latter in the application domain. Despite this initial coincidence, there are important differences: Sartoris only provides direct support for handling CPUs and main memory (upon request, it grants I$/$O privileges to programs, but without regarding the semantics of those rights), while the Exokernel exposes all the hardware, attempting to protect and isolate each application's actions. Furthermore, the Exokernel design includes software libraries that implement OS policies. Sartoris intention is to be general in that aspect.