As we have examined what operating systems look like on the outside (i.e.,the programmer's interface), it is time to take a look inside. In the next sections, we will study six different structures that have been tried, in order to get some idea of the spectrum of possibilities. These are by no means comprehensive but they give an idea of some designs that have been tried in practice. The six designs are monolithic systems, layered systems, microkernels, client-server systems, virtual machines, and exokernels.

Monolithic Systems

Undoubtedly the most common organization, in this approach the entire operating system runs as a single program in kernel mode. The operating system is written as a collection of procedures, linked together into a single large executable binary program. When this technique is used, each procedure in the system is free to call any other one, if the latter provides some useful computation that the former needs. Having thousands of procedures that can call each other without restriction often leads to an unwieldy and difficult to understand system.

To create the actual object program of the operating system when this approach is used, one first compiles all the individual procedures (or the files containing the procedures) and then binds them all together into a single executable file using the system linker. In terms of information hiding, there is basically none-every procedure is visible to every other procedure (as opposed to a structure containing modules or packages,  in which much of the information is hidden away inside modules, and only the officially designated entry points can be called from outside the module).

Even in monolithic systems, however, it is possible to have some structure. The services (system calls) provided by the operating system are requested by putting the parameters in a well-defined place (e.g., on the stack) and then executing a trap instruction. This instruction switches the machine from user mode to kernel mode and transfers control to the operating system, shown as step 6 in "SYSTEM CALLS" figure. The operating system then fetches the parameters and decides which system call is to be carried out. After that, it indexes into a table that includes in slot k a pointer to the procedure that executes system call k (step 7 in "SYSTEM CALLS" figure).

This organization suggests a basic structure for the operating system:

1. A main program that invokes the requested service procedure.
2. A set of service procedures that carry out the system calls.
3. A set of utility procedures that help the service procedures.

In this model, for each system call there is one service procedure that takes care of it and executes it. The utility procedures do things that are required by various service procedures, such as fetching data from user programs. This division of the procedures into three layers is shown in the following figure.

A simple structuring model for a monolithic system

In addition to the core operating system that is loaded when the computer is booted, many operating systems support loadable extensions, such as I/O device drivers and file systems. These components are loaded on demand.


system calls, kernel mode, i/o devices