Information Technology Reference
In-Depth Information
system vendor, changing the system call interface is a huge step, often
requiring coordination across many companies.
One of the key ideas in UNIX, responsible for much of its success, was to
design its system call interface to be simple and powerful, so that almost
all of the innovation in the system could happen in user code without
changing the interface to the operating system. The UNIX system call
interface is also highly portable | the operating system could be ported
to new hardware without needing to rewrite application code. As shown in
Figure 3.2, the kernel can be seen as a \thin waist", enabling innovation at
the application-level, and in the hardware, without requiring simultaneous
changes in the other parts of the system.
Safety. However, resource management and protection must be imple-
mented in the operating system kernel, or in a specially privileged process
called by the kernel. As we explained in the previous chapter, if appli-
cations can directly execute instructions on the processor, they can skip
any protection code in a user-level library, so protection checks cannot be
implemented at that level.
Reliability. Improved reliability is another reason to keep the operating
system kernel minimal. Kernel code needs the power to set up hardware
devices, such as the disk, and to control protection boundaries between
applications. However, kernel modules are typically not protected from
one another, and so a bug in kernel code (whether sensitive or not) may
corrupt user or kernel data. This has led some systems to use a philosophy
of \what can be at user level, should be." An extreme version of approach
is to isolate privileged, but less critical, parts of the operating system such
as the file system or the window system, from the rest of the kernel. This
is called a microkernel design. In a microkernel, the kernel itself is kept
Denition: microkernel
small, and instead most of the functionality of a traditional operating
system kernel is put into a set of user-level processes, or servers, accessed
from user applications via interprocess communication.
Performance. Finally, transferring control into the kernel is more ex-
pensive than a procedure call to a library, and transferring control to a
user-level file system server via the kernel is still even more costly. Modern
processor hardware has added various support to reduce the cost of these
boundary crossings, but the performance issue remains important. Mi-
crosoft Windows NT, a precursor to Windows 7, was initially designed as
a microkernel, but over time much of its functionality has been migrated
back into the kernel for performance reasons.
There are no easy answers! We will investigate the question of how to design
the system call interface and where to place operating system functionality
through case studies of UNIX and other systems:
