At first operating systems were designed to help applications interact with the computer hardware. While this is still the case, the importance of the operating system has grown to the point where (at least in the minds of many users) the operating system defines the machine. Most users engaged in the Mac - PC - Unix battle are arguing about the operating systems on these machines, not the hardware platform itself.
The operating system provides a layer of abstraction between the user and the bare machine. Users and applications do not see the hardware directly, but view it through the operating system.
This abstraction can be used to hide certain hardware details from users and applications. Thus, changes in the hardware are not seen by the user (even though the OS must accommodate them).
This is particularly advantageous for venders that want offer a consistent OS interface across an entire line of hardware platforms. For example, certain operations such as interaction with 3D graphics hardware can be controlled by the operating system. When an instruction pertaining to the hardware is executed and if the hardware is present then all is fine. However, if the hardware is not present then a trap is generated by the illegal instruction. In this case the OS can emulate the desired instruction in software.
Another way that abstraction can be used is to make related devices appear the same from the user point of view. For example, hard disks, floppy disks, CD-ROMs, and even tape are all very different media, but in many operating systems they appear the same to the user.
Unix, and increasingly Windows NT, take this abstraction even further. From a user and application programmer standpoint, Unix is Unix regardless of the CPU make and model. As previously mentioned, it is this feature of Unix more than any other that is responsible for Unix's popularity.
We can view an operating system as providing four basic interfaces:
interface to the underlying hardware
interface to application programs
interface to the user
interface to the system manager
Each of these interfaces provides the appropriate view for different groups of individuals:
hardware developers who want their hardware to be supported by a particular operating system are primarily interested in the OS-hardware interface.
application programmers are primarily interested in the OS-application interface.
ordinary users are interested in the user interface. Many books that purport to be about a particular operating system in fact mainly discuss the user interface.
system managers are obviously interested in the system management interface.
Most operating systems in use today are composed of two distinct parts: the kernel and the system programs. The kernel is primarily responsible for the first two of the interfaces described above, and the system programs are primarily responsible for the last two.
Processes. A key abstraction utilized in the design of an operating system is the notion of process.
A process is a program in execution.
the status of a process includes:
the code that is executing
the values of its variables
the contents of the CPU registers, especially the program counter (PC)
the state of the process (running, ready, waiting, etc.)
At any given time, the system kernel is managing a collection of processes.
some are user processes (shells, applications, etc.)
some are system processes (print spooler, accounting process, etc.)
An important kernel function is the management of processes. The kernel is responsible for creating, scheduling and deleting processes and often for inter-process communication.
Resource Allocation. Modern operating systems often provide users and applications with a virtual machine, an interface to the underlying hardware that makes it appear as though the user is the only user of the machine and it's hardware.
CPU. Whether the computer has one CPU or several CPUs, it is usually the case that there are more processes than CPUs. Thus, the operating system is responsible for scheduling the processes on the CPU(s).
Memory. There is a finite amount of memory that must be shared among the processes. The way this is done varies between different operating systems, but a commonly used mechanism is that of virtual memory.
IO devices. Several different processes may be trying to access a single IO device and the operating system must manage these accesses. Note that this is a different issue than processes scheduling since often IO is being performed for processes that are not currently executing.
Some devices (e.g. disks) have resources that can be shared among users and/or user processes. The operating system is responsible for managing and protecting these resources.
Support Services. Another important operating system task is providing support services for processes. These include:
Support for IO operations. We've already discussed how the operating system controls IO to enforce a protection scheme.
File system management.
Networking.
Protection.
Interrupts and Traps. A great deal of the kernel consists of code that is invoked as the result of a interrupt or a trap.
While the words "interrupt" and "trap" are often used interchangeably in the context of operating systems, there is a distinct difference between the two.
An interrupt is a CPU event that is triggered by some external device.
A trap is a CPU event that is triggered by a program. Traps are sometimes called software interrupts. They can be deliberately triggered by a special instruction, or they may be triggered by an illegal instruction or an attempt to access a restricted resource.
When an interrupt is triggered by an external device the hardware will save the the status of the currently executing process, switch to kernel mode, and enter a routine in the kernel.
This routine is a first level interrupt handler. It can either service the interrupt itself or wake up a process that has been waiting for the interrupt to occur.
When the handler finishes it usually causes the CPU to resume the processes that was interrupted. However, the operating system may schedule another process instead.
When an executing process requests a service from the kernel using a trap the process status information saved, the CPU is placed in kernel mode, and control passes to code in the kernel.
This kernel code is called the system service dispatcher. It examines parameters set before the trap was triggered, often information in specific CPU registers, to determine what action is required. Control then passes to the code that performs the desired action.
When the service is finished, control is returned to either the process that triggered the trap or some other process.
Traps can also be triggered by a fault. In this case the usual action is to terminate the offending process. It is possible on some systems for applications to register handlers that will be evoked when certain conditions occur -- such as a division by zero.
Operating system design is a complex task. One of the driving forces behind software engineering was the complexity of OS design. (See, for example, The Mythical Man Month by Frederick Brooks).
System design goals:
User interface: should the interface be easy to learn by a novice user, or should it be designed for the convenience of an experienced user? (multiple user interfaces?)
Efficient system resource management. Unfortunately, the more complete the resource management, the more overhead.
Security. Once again, the more secure a system is the less efficient it is.
Flexibility. Most operating systems come preconfigured for many different devices. Part of the process of setting up a particular machine is to construct a version of the operating system that is tuned for the local installation. This tuning often involves setting certain limits, such as the maximum number of processes. It also involves specifying the attached hardware so that only the necessary drivers will be loaded. Some operating systems can load and unload drivers automatically at run-time.
Portability. Will the operating system be portable to widely varying types of hardware, or just different models of a particular class of hardware?
Backwards compatibility and emulation. Is it important that software that ran under previous operating system versions or under different operating systems be supported?
Layered design:
Operating system consists of multiple layers. Each layer depends on the on the layer(s) beneath it.
Advantages:
improved security, since only layers close to hardware need to operate in kernel mode.
improved portability since only small part of operating system interfaces with the hardware.
makes maintenance of operating system code easier.
Disadvantages:
deciding what functionality to put in each layer can be difficult. This is because there are some interdependencies that would violate the layering model.
decreased efficiency.
Distinction between mechanisms and policies:
a mechanism is a facility the system provides the system manager. For example, VMS allows the manager to control whether or not a given account can be logged in to over a network connection.
a policy is a decision made by the manager(s) about how to accomplish some goal. For example, a company may decide that it will not allow privileged accounts to be logged in to over a network connection.
mechanisms are the tools used to implement policies.
In a typical multi-user system, users are expected to know that the machine is shared by other users, and that resources such as devices are shared between all the users.
In virtual machine operating systems an addition layer of abstraction is placed between the users and the system so that it appears to the user that they are using a machine dedicated to them.
Usually it is the case that a more powerful machine is used to host several virtual machines. For example, the 80386 and later Intel CPUs supported virtual 8086 machines. Thus, an operating system designed for the 80386 could actually run several copies of MS-DOS and appear to the user to be several different PCs at the same time.
Another example of a virtual machine system is the IBM 370 running the VM operating system. This allowed users to work as if they had a dedicated (but smaller, less powerful) 370 completely at their disposal.
$Id: os_function.html,v 1.1 1998/04/02 15:23:37 senning Exp senning $
These notes are largely based on a set of notes prepared by Professor Russell C. Bjork of Gordon College.