Operating System Structure

(need to review virtual memory, system calls first)

First, most important point: nothing is pure. We can classify an OS into one of the types shown here on the basis of its predominant philosophy, but there will be exceptions to the philosophy in the actual implementation. As an example, Linux is a kernelized OS, but the X windowing system is implemented as a separate process.

Monolithic

All OS functions are in one big unorganized mess

Kernelized is a subtype; some traditional OS functions are moved out of the kernel into user space. Not many references to a kernelized OS any more; today, what might have been called kernelized 20 years ago will probably be called a monolithic OS.

Layered

OS divided into layers of functionality; higher layers can call lower layers, but lower layers can't call higher layers (classic example: THE operating system, by Dijkstra). Related concept: ``protection rings'' as in Multics. Calling lower layers requires a system call; CPU has several, successively more privileged, operating modes rather than just kernel/user.

Microkernel

As many traditional OS functions as possible are removed from the kernel and moved to other processes. The difference between a kernelized and a microkernel OS is that in a kernelized OS all privileged operations remain in the kernel, but in a microkernel OS some privileged operations will be in the other processes.

Implementing this can be interesting, of course. In a computer with memory-mapped IO, we can make access to devices possible in user mode for device driver processes. The Intel architecture has the ability to enable user-mode access to IO ports on a port by port and process by process basis. On other architectures, it's necessary to implement some processes that run in kernel mode.

Commentary

The decision as to what should be in the kernel, and what should be in user-land, is likely to remain contentious far into the future. From a philosophical point of view the kernel should be as small as possible, so there is as little opportunity to introduce bugs into it as possible. However, context switches are expensive, so moving functionality into the kernel makes it more efficient. The term ``kernel bloat'' is used when one person thinks another person has moved some user-space functionality into the kernel. To my mind, a classic example of kernel bloat appears in Linux; it is now possible for the kernel to directly serve some web pages. However, people running large farms of computers doing web hosting regard this as an essential improvement of efficiency.

Microkernels really came out of a very 1970s view of software development: if you have a big piece of software, it must of necessity be bloated, unstructured, hard to understand, and hard to maintain. A lot has been learned about building large programs since then, and especially about how to control the interfaces between the various parts of the program to maintain some structure. Look at the modularization of Linux, in which modules are explicitly loaded into the OS as needed and have tightly controlled interfaces.

At the same time, microkernels really haven't worked out as planned, either. In order to reduce context switches Minix (Tanenbaum's classic academic microkernel OS) ends up being built almost exactly as he describes a monolithic OS being built, but with tightly controlled interfaces between the ``processes.''