Chapter 4: Unix Architecture Overview

Kernel
Unix is a multitasking, multiuser, operating system, designed from day one to be lean and
effective in dealing with real time processing of information. The operating system
design essentially embodies effective operating system control over resources (hard disk,
tapes, screen, filesystem, etc.), so that as many applications as possible to support over
the system can run concurrently, without problem.
The architecture of Unix is relatively simple. Unix derives most of its functionality via
the Kernel, which is a block of code that supports all interaction with end user
applications, shells, etc.
Along with the kernel, is the device drivers, which allow all applications, via the kernel,
to interact with the devices that are available within the system.
The kernel is designed to be flexible - Unix traditionally is distributed as a package of
source code files written in the C programming language. The target system hence either
has an existing Unix implementation with a C compiler, which can recompile the latest
kernel enhancements to create a new operating system image to execute after a system
shutdown and reboot.
Recently, however, due to the standardization of the PC platform (i.e.: most PCs have a
standard set of devices - floppy, hard disk(s), CDROM, high resolution video adaptor,
etc.), you can obtain precompiled Unix releases that embody the majority of features that
an end user or multi-user environment requires.
In either scenario, the kernel itself does relatively little on its own. The boot processes for
Unix (located either in a boot sector of a PC hard disk, or in ROM for high end Unix
workstations), will begin the loading procedure for the kernel. The kernel itself can be
thought of as a collection of standard functionaltiy (i.e.: fopen(), fclose(), etc.), obtainable
via system calls to the kernel from the application itself. Recall, in the DOS environment,
functions like fopen() were really wrappers around basic low level DOS services such as
opening a file handle, closing a file handle, etc. In DOS, the high level wrapper code,
which is supplied by the compiler manufacturer, will inevitably make an interrupt call to
the DOS kernel, which processes the request and supplies whatever output information is
requried.
In Unix, the high level functionality is essentially built right into the kernel. Applications
will dynamically link to the kernel when a shell or other application instructs the kernel
to execute a given program. The dynamic linking is done to avoid duplicating vast
volumes of common code from application to application (similar to the DLL concept in
Windows, but of course Microsoft makes it sound like it's a revolutionary new concept
for the PC :-)
 The kernel also contains the vast majority of the resource management functionality -
memory managers, file system management, network management, interprocess
communication management, etc. This management functionality is what Unix is famous
for - a typical Pentium running a flavour of Unix can quite easily support hundreds of
concurrent users all interacting with the system, whereas Microsoft Windows NT
generally grinds to a crawl in a similarly loaded situation - again, Windows offers
different reasons for use than does Unix, hence, Unix is not a panacea for all end user
situations, much like Windows doesn't fit the bill everywhere.
The kernel functionality, especially in process management, is top notch. Relatively little
time is spent switching from application to application in Unix, which means that the
system is far more efficient in multitasking than is Windows (however, Windows must
support the legacy of an improperly designed hardware platform for backward
compatibility - NT running on a DEC Alpha, for instance, does indeed run much more
smoothly than on a similar Pentium based workstation).
What the kernel doesn't supply is access to hardware. This is a key ingredient in the
success of Unix in terms of the number of platforms that can handle the basic system -
hardware interaction is handled via device drivers that can be customized for each
individual workstation. DOS in many respects is tied to the PC platform - much of the
low level file system support is based on the BIOS configuration and hardware
configuration of a standard PC system, which makes portability of DOS impossible (now
you know why an Apple can run a DOS app, and vice versa).
Because a Unix application will be making kernel function calls, a Unix application is
generally fully portable to any other Unix system, regardless of the vendor. Therefore,
software developers can maximize the effectiveness of a given piece of software by
writing the code in standardized C code, using the universally accepted POSIX function
set, which all modern Unix systems fully support (Windows NT used to have a posix
subsystem, but recently has dropped support for some reason :-(

Process Structure
Unix systems multitask applications in what is generally regarded as "user" mode,
whereas the kernel code itself runs in "kernel" or "privileged" mode. The differences are
important - kernel code is customized, via device drivers, for the hardware platform -
hence, the kernel can take advantage, thru device drivers, of specialized processor
functionality that make the multitasking of applications much smoother.
User mode applications, however, are restricted in their ability to access certain processor
instructions, and furthermore, the system is able to keep tabs on what an application does
with resources such as memory, files, etc., independent of any other application. Such
concepts like memory management, virtual memory, etc., are not new to the Unix world -
they were implemented years ahead of the DOS/Windows environment because Unix
needs them to operate!
The user mode applications are thus protected from one another through the restrictions
placed on the user mode code. Because priviledged instructions cannot be used, and
 because memory access can be monitored via the system, user level code generally does
not corrupt the kernel if improper coding has been encountered. Unix applications, if they
perform operations that are deemed priviledged, the operating system itself can shut the
application down with "priviledge" faults, "page" faults (memory access), and other
conditions.
This is similar, and generally better supported than the similar feature of Windows that
we are all familiar with - General Protection Faults (GPFs). Windows as well can shut
down faulty programs because Windows has no choice but to support multitasking in a
Unix fashion - chaos would easily erupt if it didn't!

Input/Output and Piping

Unix console applications work in a similar fashion as do Windows console applications:
they both support keyboard oriented input, and text mode output.
Unix supports all standard input/output mechanisms, including C functions like printf(),
gets() and so forth. Just like with a Windows console, these standard sources can be
redirected.
Thus, the output of a given command can be directed to a file or device by using the ‘>’
symbol (greater than) to direct the output from the normal “stdout” destination. The input
of a given command can be read from a file or device by using the ‘<’ symbol (less than)
to pull the input from a file rather than the normal “stdin” destination.
Unix generally supports the ability to select which input or output source you wish to
redirect. Prefacing a digit in front of the input or output redirection symbol does this. 0
indicates stdin, 1 indicates stdout, and 2 indicates stderr (the error destination which
normally isn’t redirected).
Thus, if you wish to capture the error output of a command, try:
command 2> filename

This forces the stderr output (file source 2) and places it into the file called “filename”.
You are also able to use the industry standard pipe symbol (the vertical bar ‘|’), to allow
the output of one command to flow into the input of another command. Unlike earlier
versions of MS-DOS, Unix will truly multitask both applications, thus, during the
timeslice of the first program, output will be generated into the FIFO object automatically
created by the shell, and during the timeslice of the second program, data will be read
from the FIFO. This continues until both applications are complete.