Dual-mode operation

reading and writing memory, managing

OS Structure, resources, accessing I/O... would you ! !
trust this to HIM?
Processes & Solution: dual mode operation

Process Management “User Mode”: can only perform a restricted

set of operation (applications)

“Supervisor Mode” : can do anything! (Kernel)

How would you implement dual mode operation?

1

Dual-mode operation Crossing the line

reading and writing memory, managing user process mode bit = 1

resources, accessing I/O... would you ! ! user process executing calls system call return from system call

trust this to HIM?

Solution: dual mode operation trap mode bit := 1

“User Mode”: can only perform a restricted mode bit := 0 return

set of operation (applications)
kernel mode bit = 0
“Supervisor Mode” : can do anything! (Kernel) execute system call

Hardware to the rescue! Use a mode bit

 Crossing the line On Interrupts
1. Driver tells disk controller
Three ways to go from user to supervisor what to do by writing into
device registers
mode:

Interrupts: HW device requests OS service-

asynchronous
Disk
drive
Traps: user program requests OS service
(system call)–synchronous
Interrupt Disk
Exceptions: user program acts silly (e.g. CPU Controller Controller
divide by zero)–synchronous

On Interrupts On Interrupts
1. Driver tells disk controller 1. Driver tells disk controller 3. Interrupt controller asserts
what to do by writing into what to do by writing into pin on CPU to signal interrupt
device registers device registers
2. When it’s done, uses bus lines 2. When it’s done, uses bus lines
to signal interrupt controller to signal interrupt controller
chip chip

Disk Disk
drive drive

Interrupt Disk Interrupt Disk

CPU Controller Controller
CPU Controller Controller
 On Interrupts On Interrupts
Hardware calls OS at a pre-
1. Driver tells disk controller 3. Interrupt controller asserts specified location by changing irq action
what to do by writing into pin on CPU to signal interrupt voltage on pins)
9
device registers
4. Interrupt controller puts OS saves state of user program handler
Interrupt
2. When it’s done, uses bus lines device # on the bus for CPU 8
flags
handling
OS identifies device and cause routine for
to signal interrupt controller to read name this device
of interrupt 7
next
chip
OS responds to the interrupt 6

Disk
drive
OS restores state of the user 5
program (if applicable) or some 4
other user program
3 Linux
OS executes an RTI instruction
Interrupt Disk interrupt handling
to return to the user program
CPU Controller Controller
2
data structures
User program continues where 1
it was interrupted.
0
Key Fact: None of this is visible to
the user program

On Exceptions System calls

Programming interface Example: Copying a file
Hardware calls OS at a pre-specified location to the services provided Acquire input file name
OS identifies cause of exception (e.g. divide by 0) by the OS Write prompt to screen
Accept input
If user program has exception handling specified, Mostly accessed through Acquire output file name

then OS adjusts user program state so that it an API (Application

Write prompt to screen
Accept input
calls its handler
Programming Interface) Open the input file
If file does not exist, abort
Execute RTI to return to the user program
Win32, POSIX, Java Create output file

If user program did not have a specified handler, API

If file exists, abort
Loop
then OS kills it and runs some other user Read from input file
program, as available Parameters passed in Write to output file
registers Until read fails
Key Fact: Effects of exceptions are visible to user table (pointed by register)
Close output file
Write completion message to screen
programs and cause abnormal execution flow stack Terminate normally
 System call
implementation
A number associated
with each system call
System call interface
maintains a mapping
between number and
code
Typically, all caller needs
to know is API!
On System Calls
User program executes a trap instruction
User Program (system call)
Hardware calls OS at a pre-specified location
open()
OS identifies the required service and
parameters (e.g. open(filename, O_RDONLY))
system call interface
OS executes the required service
open() OS sets a register to contain the result of call
implementation of
i open() system call OS executes RTI to return to the user program
.
.
User program receives the result and continues
. Key Fact: To the user program, it appears as a
return
function call executed under program control

Summary Internal OS Structure

An OS is just a program:
It has a main() function, called only once (during boot)
It consumes resources (such as memory), can do silly
things (like generating an exception), etc.
OS provides a more convenient interface than
But it is a very strange program: the raw hardware interface
It is “entered” from different locations in response to
external events
The structure of the OS affects both the
It does not have a single thread of control and can be
abstractions provided by the OS and their
invoked simultaneously by two different events (e.g. implementation
system call & an interrupt)
It is not supposed to terminate
It can execute any instruction in the machine
 Monolithic structure Monolithic structure
(e.g. Unix) (e.g. Unix)

Application Application Application Application Application Application Application Application

API

Everything
File Memory Manager Process Manager Boot & Network
System Init Support
Device Interrupt
Extensions & Add’l devices Drivers handlers Protection

Hardware Abstraction Layer

Hardware Hardware
Advantages? !! ! ! Disadvantages?

Microkernels
Layered OS
(e.g. Mach, Chorus)
Users programs Minimize kernel services,
Each system service is a (see virtual I/O drivers) implement remaining OS
Client (user) programs

layer Device buffers modules as (protected) user

(sees a Virtual Console) Network
level processes OS
File System
Each layer defines and Console and IPC modules Windowing
implements an abstraction (sees Virtual Memory) Client/Server interaction, (servers)
Memory
Manager
for the layer above it Memory management mediated by uniform
CPU Scheduling

(sees virtual processors) message passing interface Basic Message Passing

Layers in effect
Interrupt Handling, Microkernel
“virtualize” the layer below Examples: Hydra (1970), Device drivers Interrupt Boot &
CPU Scheduling
MACH, Chorus, NT ... handlers init

Advantages? Disadvantages? Hardware

Hardware
Advantages? Disadvantages?
THE System (EWD 1968)
http://www.cs.utexas.edu/~EWD/ewd01xx/EWD196.PDF
 Awakening the Giant:
Virtual Machine Monitors
System boot
Virtualize hardware to What happens when you turn the power on?
run multiple operating App 3
systems 1. CPU loads boot program from ROM
App 2 App 2 App 2
Which part is 2. Boot program (BIOS in PCs):
App 1 App 1 App 1 App 1
“supervisor mode”? Examines/checks machine configuration (number of CPU’s, how
OS1 OS2 OS3 OS4 much memory, number & type of HW devices, etc.)
What happens on a Builds a configuration structure describing the hardware
system call? Loads the bootloader
Virtual Machine Monitor
from “well-known” memory location (e.g. 1st sector of hard
On an interrupt? disk)
Hardware
to “well known” memory location (0x7c00 to 0x7dff in Bochs)
Jumps to bootloader code at “well-known” entry point

Awakening the Giant:

A sleepy Giant...
The bootloader
3. Bootloader: 5. Once the OS is initialized
Run user programs if available; else run low-priority user-
Initializes stuff level idle-process
SP = initial stack at well-known location
In the idle process
Read OS from disk, jump to well-known entry point
infinite loop (Unix)
4. OS initialization system management and profiling
halt processor and enter low-power mode (notebooks)
initialize kernel data structures compute some function (DEC’s VAX VMS computed !)
initialize state of HW devices
OS wakes up on
initialize VM system
interrupts from HW devices
creates a number of processes to start operations (e.g.
traps from user programs
daemons tty in Unix, windowing system in NT): soon’ we’ll
see how... exceptions from user programs
 Getting to know you
A process is a program during execution
Program = static file (image)

Processes Process = executing program = program +

execution state
It is a sequential stream of execution in its own
address space
At a minimum, process execution requires:
1. Memory to contain the program code and data

2. A set of CPU registers to support execution

Of Programs and Processes Keeping track of a process

More to a process than just a program A process has code

I run ls, you run ls - same program- but OS must track program counter
different processes A process has a stack
Less to a process than a program OS must track stack pointer

A program can invoke many processes to get OS stores state of processes’ computation in a
the job done (e.g. cc starts up cpp, cc1, process control block (PCB)
cc2, as–each a different process (and Data (program instructions, stack & heap)
program!)) resides in memory, metadata is in PCB
Anatomy of a Process Running a program
mapped segments
A program consists of Program starts running
Process’s DLL’s
Header code and data at _start()
address space Stack _start(args) {
Code On running a program, ! ret = main(args);
the loader: ! exit(ret)
Process Control }
Initialized data reads & interprets
Block executable
sets up the process’s When main() returns,
PC
Heap memory to contain the OS calls “exit()” which
Stack Pointer code & data from
executable
destroys the process
Registers
PID
Initialized data pushes “argc”, “argv” on and returns all its
UID the stack resources
Priority Code sets the CPU registers
properly & calls “__start()”
Executable File List of open files
…

Process Life Cycle Process Life Cycle

Processes are always either executing, waiting to Processes are always either executing, waiting to
execute or waiting for an event to occur execute or waiting for an event to occur

Process transitions from Process transitions from

New New
New to Ready when it New to Ready when it
becomes runnable becomes runnable

Ready
 Process Life Cycle Process Life Cycle
Processes are always either executing, waiting to Processes are always either executing, waiting to
execute or waiting for an event to occur execute or waiting for an event to occur

Process transitions from Process transitions from

New Start
Ready to Running when Ready to Running when
kernel schedules it kernel schedules it

Ready Ready Running

Process Life Cycle Process Life Cycle

Processes are always either executing, waiting to Processes are always either executing, waiting to
execute or waiting for an event to occur execute or waiting for an event to occur

Process transitions from Process transitions from

Start Start
Running to Waiting when Running to Waiting when
they are blocked, waiting they are blocked, waiting
for an event to occur (e.g. for an event to occur (e.g.
Ready Running I/O) Ready Running I/O)

Waiting
 Process Life Cycle Process Life Cycle
Processes are always either executing, waiting to Processes are always either executing, waiting to
execute or waiting for an event to occur execute or waiting for an event to occur

Process transitions from Process transitions from

Start Start
Waiting to Ready on an Waiting to Ready on an
I/O or event completion I/O or event completion

Ready Running Ready Running

Is that it?

Waiting Waiting

Process Life Cycle Process Life Cycle

Processes are always either executing, waiting to Processes are always either executing, waiting to
execute or waiting for an event to occur execute or waiting for an event to occur

Process transitions from Process transitions from

Start Start
Running to Ready on an Running to Ready when
interrupt scheduler picks another
process (e.g. on a timer
Ready Running Ready Running interrupt)

Waiting Waiting
 Process Life Cycle Process Life Cycle
Processes are always either executing, waiting to Processes are always either executing, waiting to
execute or waiting for an event to occur execute or waiting for an event to occur

Process transitions from Process transitions from

Start Start Done
Running to Done on exit() Running to Done on exit()

Ready Running Ready Running

Waiting Waiting

What happens on a
read()?

Start Done

Ready Running

Waiting