What’s an OS?

It’s a program that mediates between application programs

and the hardware
It provides abstractions to simplify building applications:
files instead of “bytes on a disk”
contiguous memory regions instead of “bits in a RAM chip”
processes to run applications
It allows application programs to co-exist peacefully
enforces security policies
enforces safety measures
Allows effective usage of hardware resources
 Hardware Support

Operating system needs to:

control I/O devices
control access to the hardware
all while denying these privileges to user programs:
for protection
for abstraction/ease of use
Hardware supports two modes of operation (or more):
access to hardware & I/O devices is done through privileged
instructions, these are only available in “supervisor” mode
privileged instructions cannot be executed in “user” mode
 Implementation

Using a bit in the processor

Using protection rings (Intel Pentium uses 4 protection rings)
Operating system code runs in supervisor mode, while user
program code runs in user mode
Switching from user to supervisor mode occurs on:
interrupts: hardware devices needing service
exceptions: user program acts silly (divide by 0, bus error, etc)
trap instructions: user program requires OS service (system call)
Switching back occurs by an RTI instruction
 On Interrupts
Hardware calls the operating system at a pre-specified location
Operating system saves state of the user program
Operating system identifies the device and cause of interrupt
Responds to the interrupt (possibly killing program, <CTRL-C>)
Operating system restores state of the user program (if applicable) or some
other user program
Execute an RTI instruction to return to the user program
User program continues exactly at the same point it was interrupted.
Key Fact: None of this is visible to the user program
 On Exceptions
Hardware calls the operating system at a pre-specified location
Operating system identifies the cause of the exception (e.g. / 0)
If user program has exception handling specified, then OS adjust the user
program state so that it calls its handler
Execute an RTI instruction to return to the user program
If user program did not have a specified handler, then OS kills it and runs
some other user program, as available
Key Fact: Effects of exceptions are visible to user
programs and cause abnormal execution flow
 On System Calls
User program executes a trap instruction (system call)
Hardware calls the operating system at a pre-specified location
Operating system identifies the required service and parameters (e.g.
open(filename, O_RDONLY);
Operating system executes the required service
Operating system sets a register to contain the result of call
Execute an RTI instruction to return to the user program
User program receives the result and continues
Key Fact: To the user program, it appears as a
function call executed under program control
 Implications on OS Structure

An OS is just a program:
It has a main() function, which gets called only once (during boot)
Like any program, it consumes resources (such as memory), can do
silly things (like generating an exception), etc.
But it is a very strange program:
It is “entered” from different locations in response to external events
It does not have a single thread of control, it can be invoked
simultaneously by two different events (e.g. sys call & an interrupt)
It is not supposed to terminate
It can execute any instruction in the machine
 Control Flow in an OS
From boot
main()
System call
Initialization Interrupt

Exception

Idle
Loop
Operating System Modules

RTI
 General OS Structure
Monolithic
App App App Structure. e.g. UNIX

API

File Memory Process

Network
Systems Manager Manager
Support

Security Service
Module Module

Extensions & Device Interrupt Boot &

Add’l device drivers Drivers handlers init
 Layered Organization
Layered
App App App Structure. e.g. Windows NT

Each API
module Process Network Object
File Memory
has a well Manager Support Support
Systems Manager
defined
interface
Kernel: M/C dependent basic implementations

Hardware Adaptation Layer (HAL)

Boot &
Extensions & Device Interrupt init
Add’l device drivers Drivers handlers
 Micro-Kernel Organization
OS main functions
implemented by App Memory App
out-of-kernel Manager
servers
Process Security
e.g.: QNX, Manager Module
File
Mach Systems Network
Support

Basic Message Passing Support

Extensions & Device Interrupt Boot &

Add’l device drivers Drivers handlers init
 Virtual Machine Organization

App App App App App App App App App

OS-1 OS-2 OS-3

e.g. OS/370 Gives a hardware

VM Layer
abstraction to the OS’es
involved (sometimes called
hypervisor)
 An Operating System in Action

CPU loads boot program from ROM (e.g. BIOS in PC’s)

Boot program:
Examines/checks machine configuration (number of CPU’s, how
much memory, number & type of hardware devices, etc.)
Builds a configuration structure describing the hardware
Loads the operating system, and gives it the configuration structure
Operating system initialization:
Initialize kernel data structures
Initialize the state of all hardware devices
Creates a number of processes to start operation (e.g. getty in UNIX,
the Windowing system in NT, e.g.)
 O.S. in Action (cont’d)

After basic processes have started, the OS runs user programs,

if available, otherwise enters the idle loop
In the idle loop:
OS executes an infinite loop (UNIX)
OS performs some system management & profiling
OS halts the processor and enter in low-power mode (notebooks)
OS computes some function (DEC’s VMS on VAX computed Pi)
OS wakes up on:
interrupts from hardware devices
traps from user programs
exceptions from user programs