1.
6 ARCHITECTURE OF THE UNIX OPERATING SYSTEM
It has been noted (see page 239 of [Christian 831) that the UNIX system supports. The illusions
that the file system has “places” and that process have “life”. The two entities, files and
processes, are the two central concepts in the UNIX system model.
Figure [Block Diagram of System Kernel] gives a block diagram of the kernel, showing various
modules and their relationships to each other. In particular, it shows the file subsystem on the
left and the process control subsystem on the right, the two major components of the kernel. The
diagram serves as a useful logical view of the kernel, although in practice the kernel deviates
from the model because some modules interact with the internal operations of others.
Figure [Block Diagram of System Kernel] shows three levels: user, kernel, and hardware. The
system call and library interface represent the border between user programs and the kernel
depicted in Figure I.I. System calls look like ordinary function calls in C programs, and libraries
map these function calls to the primitives needed to enter the operating system as covered in
more detail in Chanter 6 Assembly language programs may invoke system calls directly
without a system call library, however. Programs frequently use other libraries such as the
standard 1/O library to provide a more sophisticated use of the system calls. The libraries are
linked with the programs at compile time and are thus part of the user program for purposes of
this discussion. An example later on will illustrate these points.
The figure partitions the set of system calls into those that interact with the file
subsystem and those that interact with the process control subsystem. The file
subsystem manages files, allocating file space, administering free space, controlling
access to files, and retrieving data for users. Processes interact with the file
subsystem via a specific set of system calls, such as open (to open a file for reading
or writing), close, read, write, stat (query the attributes of a file), chown (change the record of
who owns the file), and chmod (change the access permissions of a file). The file subsystem
accesses file data using a buffering mechanism that regulates
data flow between the kernel and secondary storage devices. The buffering mechanism with
block i/o device driver to initiate data transfer to and from the kernel. Device drivers are the
kernel modules that control the operation of peripheral devices. Block I/O devices are random
access storage devices; alternatively, their device drivers make them appear to be random access
storage devices to the rest of the system. For example, a tape driver may allow the kernel to treat
a tape unit as a random access storage device. The file subsystem also interacts directly with
"raw" I/O device drivers without the intervention of abuffering mechanism. Raw devices,
sometimes called character devices, include all devices that are not block devices.
The process control subsystem is responsible for process synchronization, inter process
communication, memory management, and process scheduling. The file subsystem and the
process control subsystem interact when loading a tile into memory for execution. The process
subsystem reads executable files into memory before executing them. Some of the system calls
for controlling processes are fork (create a new process), exec(overlay the image of a
program onto the running process), exit(finish executing the process ) , wait (synchronize
process execution with exit of a previously forked process), brk (control the size of memory
allocated to a process), and signal (control process response to extraordinary events).
The memory management module controls the allocation of memory. If at any
time the system does not have enough physical memory for all processes, the kernel
moves them between main memory and secondary memory so that all processes get
a fair chance to execute. Two policies for managing memory: swapping and demand paging. The
swapper process is sometimes called the scheduler, because it "schedules" the allocation of
memory for processes and influences the operation of the CPU scheduler. However, this text will
refer to it as the swapper to avoid confusion with the CPU scheduler.
The scheduler module allocates the CPU to processes. It schedules them to run
in turn until they voluntarily relinquish the CPU while awaiting a resource or until
the kernel preempts them when their recent run time exceeds a time quantum. The scheduler then
chooses the highest priority eligible process to run; the original process will run again when it is
the highest priority eligible process available.
There are several forms of inter process communication, ranging from asynchronous signaling of
events to synchronous transmission of messages between processes. Finally the hardware control
is responsible for handling interrupts and for communicating with the machine. Devices such as
disks or terminals may interrupt the CPU while a process is executing. If so, the kernel may
resume execution of the interrupted process after servicing the interrupt: interrupts are not
serviced by special processes but by special functions in the kernel, called in the context of the
currently running process.
