1. Architectural Support for Operating Systems

2. Announcements
Required textbook should be in Cornell store soon (perhaps this week)

3. Today’s material I/O subsystem and device drivers Interrupts and traps
Protection, system calls and operating mode
OS structure
What happens when you boot a computer?

4. Computer System Architecture
Synchronizes
memory access

5. I/O operations I/O devices and the CPU can execute concurrently.
I/O is moving data between device & controller’s buffer
CPU moves data between controller’s buffer & main memory
Each device controller is in charge of certain device type.
May be more than one device per controller
SCSI can manage up to 7 devices
Each device controller has local buffer, special registers
A device driver for every device controller
Knows details of the controller
Presents a uniform interface to the rest of OS

6. Accessing I/O Devices Memory Mapped I/O Programmed I/O
I/O devices appear as regular memory to CPU
Regular loads/stores used for accessing device
This is more commonly used
Programmed I/O
Also called “channel” I/O
CPU has separate bus for I/O devices
Special instructions are required
Which is better?

7. Polling I/O Each device controller typically has:
Data-in register (for host to receive input from device)
Data-out (for host to send output to device)
Status register (read by host to determine device state)
Control register (written by host to invoke command)

8. Polling I/O handshaking:
To write data to a device:
Host repeatedly reads busy bit in status register until clear
Host sets write bit in command register and writes output in data-out register
Host sets command-ready bit in control register
Controller notices command-ready bit, sets busy bit in status register
Controller reads command register, notices write bit: reads data-out register and performs I/O (magic)
Controller clears command-ready bit, clears the error bit (to indicate success) and clears the busy bit (to indicate it’s finished)

9. Polling I/O What’s the problem?
CPU could spend most its time polling devices, while other jobs go undone.
But devices can’t be left to their own devices for too long
Limited buffer at device - could overflow if doesn’t get CPU service.
Modern operating systems uses Interrupts to solve this dilemma.
Interrupts: Notification from interface that device needs servicing
Hardware: sends trigger on bus
Software: uses a system call

10. Interrupts
CPU hardware has a interrupt-request line (a wire) it checks after processing each instruction.
On receiving signal Save processing state
Jump to interrupt handler routine at fixed address in memory
Interrupt handler:
Determine cause of interrupt.
Do required processing.
Restore state.
Execute return from interrupt instruction.
Device controller raises interrupt, CPU catches it, interrupt handler dispatches and clears it.
Modern OS needs more sophisticated mechanism:
Ability to defer interrupt
Efficient way to dispatch interrupt handler
Multilevel interrupts to to distinguish between high and low priority interrupts.

11. Modern interrupt handling
Use a specialized Interrupt Controller
CPUs typically have two interrupt request lines:
Maskable interrupts: Can be turned of by CPU before critical processing
Nonmaskable interrupts: signifies serious error (e.g. unrecoverable memory error)
Interrupts contain address pointing to interrupt vector
Interrupt vector contains addresses of specialized interrupt handlers.
If more devices than elements in interrupt vector; do interrupt chaining:
A list of interrupt handlers for a given address which must be traversed to determine the appropriate one.
Interrupt controller also implements interrupt priorities
Higher priority interrupts can pre-empt processing of lower priority ones

12. Even interrupts are sometimes to slow:
Device driver loads controller registers appropriately
Controller examines registers, executes I/O
Controller signals I/O completion to device driver
Using interrupts
High overhead for moving bulk data (i.e. disk I/O):
One interrupt per byte..

13. Direct Memory Access (DMA)
Transfer data directly between device and memory
No CPU intervention
Device controller transfers blocks of data
Interrupts when block transfer completed
As compared to when byte is completed
Very useful for high-speed I/O devices

14. Example I/O Instruction execution cycle Memory Instructions and Data
Thread of
execution
cache
Data movement
CPU (*N)
I/O Request
Interrupt
Data
DMA
Disk Device Driver
and
Disk Controller
Keyboard Device Driver
and
Keyboard Controller
Perform I/O
Read Data

15. Interrupt Timeline

16. Traps and Exceptions Software generated interrupt
Exception: user program acts silly
Caused by an error (div by 0, or memory access violation)
Just a performance optimization
Trap: user program requires OS service
Caused by system calls
Handled similar to hardware interrupts:
Stops executing the process
Calls handler subroutine
Restores state after servicing the trap

17. Why Protection? Application programs could: Other users could be:
Start scribbling into memory
Get into infinite loops
Other users could be:
Gluttonous
Evil
Or just too numerous
Correct operation of system should be guaranteed
 A protection mechanism

18. Preventing Runaway Programs
Also how to prevent against infinite loops
Set a timer to generate an interrupt in a given time
Before transferring to user, OS loads timer with time to interrupt
Operating system decrements counter until it reaches 0
The program is then interrupted and OS regains control.
Ensures OS gets control of CPU
When erroneous programs get into infinite loop
Programs purposely continue to execute past time limit
Setting this timer value is a privileged operation
Can only be done by OS

19. Protecting Memory Protect program from accessing other program’s data
Protect the OS from user programs
Simplest scheme is base and limit registers:
Virtual memory and segmentation are similar
memory
Prog A
Base register
Loaded by OS before
starting program
Prog B
Limit register
Prog C

20. Protected Instructions
Also called privileged instructions. Some examples:
Direct user access to some hardware resources
Direct access to I/O devices like disks, printers, etc.
Instructions that manipulate memory management state
page table pointers, TLB load, etc.
Setting of special mode bits
Halt instruction
Needed for:
Abstraction/ease of use and protection

21. Dual-Mode Operation
Allows OS to protect itself and other system components
User mode and kernel mode
OS runs in kernel mode, user programs in user mode
OS is god, the applications are peasants
Privileged instructions only executable in kernel mode
Mode bit provided by hardware
Can distinguish if system is running user code or kernel code
System call changes mode to kernel
Return from call using RTI resets it to user
How do user programs do something privileged?

22. Crossing Protection Boundaries
User calls OS procedure for “privileged” operations
Calling a kernel mode service from user mode program:
Using System Calls
System Calls switches execution to kernel mode
User Mode
Mode bit = 1
Resume process
User process
System Call
Trap
Mode bit = 0
Kernel Mode
Mode bit = 0
Return
Mode bit = 1
Save Caller’s state
Execute system call
Restore state

23. System Calls Programming interface to services provided by the OS
Typically written in a high-level language (C or C++)
Mostly accessed by programs using APIs
Three most common APIs:
Win32 API for Windows
POSIX API for POSIX-based systems (UNIX, Linux, Mac OS X)
Java API for the Java virtual machine (JVM)

24. Types of System Calls Process Control File Management
end or abort process; create or terminate process, wait for some time; allocate or deallocate memory
File Management
open or close file; read, write or seek
Device Management
attach or detach device; read, write or seek
Information Maintenance
get process information; get device attributes, set system time
Communications
create, open, close socket, get transfer status.

25. System call sequence to copy contents of one file to another
Why APIs?
System call sequence to copy contents of one file to another
Standard API

26. Reducing System Call Overhead
Problem: The user-kernel mode distinction poses a performance barrier
Crossing this hardware barrier is costly.
System calls take 10x-1000x more time than a procedure call
Solution: Perform some system functionality in user mode
Libraries (DLLs) can reduce number of system calls,
by caching results (getpid) or
buffering ops (open/read/write vs. fopen/fread/ fwrite).

27. Real System Have Holes OSes protect some things, ignore others
Most will blow up when you run:
Usual response: freeze
To unfreeze, reboot
If not, also try touching memory
Duality: Solve problems technically and socially
Technical: have process/memory quotas
Social: yell at idiots that crash machines
Similar to security: encryption and laws
int main() {
while (1) {
fork(); }

28. Fixed Pie, Infinite Demands
How to make the pie go further?
Resource usage is bursty! So give to others when idle.
Eg. When waiting for a webpage! Give CPU to idle process.
Ancient idea: instead of one classroom per student, restaurant per customer, etc.
BUT, more utilization  more complexity.
How to manage? (1 road per car vs. freeway)
Abstraction (different lanes), Synchronization (traffic lights), increase capacity (build more roads)
But more utilization  more contention.
What to do when illusion breaks?
Refuse service (busy signal), give up (VM swapping), backoff and retry (Ethernet), break (freeway)

29. Fixed Pie, Infinite Demand
How to divide pie?
User? Yeah, right.
Usually treat all apps same, then monitor and re-apportion
What’s the best piece to take away?
OSes are the last pure bastion of fascism
Use system feedback rather than blind fairness
How to handle pigs?
Quotas (leland), ejection (swapping), buy more stuff (microsoft products), break (ethernet, most real systems), laws (freeway)
A real problem: hard to distinguish responsible busy programs from selfish, stupid pigs.

30. How do you start the OS?
Your computer has a very simple program pre-loaded in a special read-only memory
The Basic Input/Output Subsystem, or BIOS
When the machine boots, the CPU runs the BIOS
The bios, in turn, loads a “small” O/S executable
From hard disk, CD-ROM, or whatever
Then transfers control to a standard start address in this image
The small version of the O/S loads and starts the “big” version.
The two stage mechanism is used so that BIOS won’t need to understand the file system implemented by the “big” O/S kernel
File systems are complex data structures and different kernels implement them in different ways
The small version of the O/S is stored in a small, special-purpose file system that the BIOS does understand

31. What does the OS do?
OS runs user programs, if available, else enters 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

32. OS Control Flow From boot main() System call Initialization Interrupt
Exception
Idle
Loop
Operating System Modules
RTI

33. Operating System Structure
Simple Structure: MS-DOS
Written to provide the most functionality in the least space
Applications have direct control of hardware
Disadvantages:
Not modular
Inefficient
Low security

34. General OS Structure Monolithic Structure App App App API Memory
Manager
File
Systems
Process
Manager
Network
Support
Security
Module
Service
Module
Extensions &
Add’l device drivers
Device
Drivers
Interrupt
handlers
Boot &
init
Monolithic Structure

35. Layered Structure OS divided into number of layers Advantages:
bottom layer (layer 0), is the hardware
highest (layer N) is the user interface
each uses functions and services of only lower-level layers
Advantages:
Simplicity of construction
Ease of debugging
Extensible
Disadvantages:
Defining the layers
Each layer adds overhead

36. Layered Structure App App App API File Systems Memory Manager Process
Network
Support
Object
Support
M/C dependent basic implementations
Hardware Adaptation Layer (HAL)
Boot &
init
Extensions &
Add’l device drivers
Device
Drivers
Interrupt
handlers

37. Microkernel Structure
Moves as much from kernel into “user” space
User modules communicate using message passing
Benefits:
Easier to extend a microkernel
Easier to port the operating system to new architectures
More reliable (less code is running in kernel mode)
More secure
Example: Mach, QNX
Detriments:
Performance overhead of user to kernel space communication
Example: Evolution of Windows NT to Windows XP

38. Microkernel Structure
Memory
Manager
App
App
Process
Manager
Security
Module
File
Systems
Network
Support
Basic Message Passing Support
Extensions &
Add’l device drivers
Device
Drivers
Interrupt
handlers
Boot &
init

39. Modules Most modern OSs implement kernel modules
Uses object-oriented approach
Each core component is separate
Each talks to the others over known interfaces
Each is loadable as needed within the kernel
Overall, similar to layers but with more flexible
Examples: Solaris, Linux, MAC OS X

40. UNIX structure

41. Windows Structure

42. Modern UNIX Systems

43. MAC OS X

44. Virtual Machines Implements an observation that dates to Turing
One computer can “emulate” another computer
One OS can implement abstraction of a cluster of computers, each running its own OS and applications
Incredibly useful!
System building
Protection
Cons
implementation
Examples
VMWare, JVM,
CLR, Xen+++

45. VMWare Structure

46. But is it real?
Can the OS know whether this is a real computer as opposed to a virtual machine?
It can try to perform a protected operation… but a virtual machine monitor (VMM) could trap those requests and emulate them
It could measure timing very carefully… but modern hardware runs at variable speeds
Bottom line: you really can’t tell!

47. Modern version of this question
Can the “spyware removal” program tell whether it is running on the real computer, or in a virtual machine environment created just for it (by the spyware)?
Basically: no, it can’t!
Vendors are adding “Trusted Computing Base” (TCB) technologies to help
Hardware that can’t be virtualized
We’ll discuss it later in the course