Example: major Unix tables
The following figure shows major tables in a classic Unix implementation.
per process region table
open files table
region table inode table
page table swap use table
pointer to entry in table pointer to data structure
process table u area
file desc table
Process table — this table contains an entry for each process. Additional data about
the process is maintained in the u-area. The u-area and process table enry point to each other.
File related tables — the u-area of each process contains the file descriptors table for
that process. Entries in this table point to entries in the open files table. These, in turn, point to entries in the inode table. The information in each inode contains the
device on which the file is stored.
Memory related tables — the u-area also contains a per-process region table, whose
entries point to entries in the global region table, which describe different memory regions. Data maintained for a region includes a pointer to the inode used to initial-
ize this region, and a page table for the region. This, in turn, contains a pointer to where the backup for each page is stored in the swap area.
problems: code instability and security risks due to global address space. any driver can modify core kernel data. need to lock correctly. see linus vs. tanenbaum
11.2.3 Preemption
preempting the operating system for better responsiveness [2]. fits with partitioning interrupt handling. must not wait for IO.
11.3 Microkernels
Microkernels take the idea of doing things outside of the kernel to the limit. 193
Microkernels separate mechanism from policy
The reason for using microkernels is modularity. The microkernel provides the mech- anisms to perform various actions, such as dispatching a process or reading a disk
block. However, that is all it does. It does not decide which process to run — this is the work of an external scheduling server. It does not create named files out of
disk blocks — this is the work of an external file system server. Thus it is possible to change policies and services by just replacing the external servers, without changing
the microkernel.
Microkernels are thus named because they are supposed to be much smaller than a conventional kernel. This is a natural result of the fact that a lot of functionality
was moved out of the kernel. The main things that are left in the kernel are • Multitasking and process or thread dispatch. The microkernel will do the actual
context switch, and will also schedule interrupt handlers. • Message passing among user processes. This is needed to pass systems calls
from user applications to the servers that handle them. • The mechanics of memory mapping and disk access.
To read more: The concept of microkernels was developed in the Mach operating system [4].
microkernel contains all hardware-specific code for implementing mechanisms. servers implementing policies are portable.
In particular, interrupt handling is divided into two parts
The distinction between the microkernel and the servers extends to interrupt han- dling. The interrupt handler invoked by the hardware is part of the microkernel. But
this function typically cannot actually handle the interrupt, as this should be done subject to policy decisions of the external servers. Thus a microkernel architecture
naturally creates the partitioning of interrupt handlers into two parts that was done artificially in monolithic systems.
Note that this also naturally inserts a potential preemption point in the handling of interrupts, and in fact of any kernel service. This is important for improved respon-
siveness.
External servers can have different personalities
The system’s policies and the services it provides are what differentiates it from other systems. Once these things are handled by an external server, it is possible to support
multiple system personalities at once. For example, Windows NT can support Win- dows applications with its Windows server, OS2 applications with its OS2 server,
and Unix applications with its Unix server. Each of these servers supplies unique interfaces and services, which are implemented on top of the NT microkernel.
194
In addition, the fact that services are provided by independent processes makes it easier to debug them, and also makes it possible to add and remove services while
the system is running.
But performance can be a problem
The price is overhead in communicating between the different modules. For example, when a user application wants to read a file, the system first has to switch to the file
system server. It also has to route messages back and forth between the application and the server.
user file system
microkernel application
server
hardware
11.4 Extensible Systems
