Embed Size (px)
Citation preview
1
OS Structure,Processes &
Process Management
Dual-mode operation
reading and writing memory, managing resources, accessing I/O... would you ! ! trust this to HIM?
Solution: dual mode operation
“User Mode”: can only perform a restricted set of operation (applications)
“Supervisor Mode” : can do anything! (Kernel)
How would you implement dual mode operation?
Dual-mode operation
reading and writing memory, managing resources, accessing I/O... would you ! ! trust this to HIM?
Solution: dual mode operation
“User Mode”: can only perform a restricted set of operation (applications)
“Supervisor Mode” : can do anything! (Kernel)
Hardware to the rescue! Use a mode bit
Crossing the line
user process
kernel
user process executing calls system call return from system call
execute system call
trap
mode bit := 0
mode bit := 1
return
mode bit = 1
mode bit = 0
Crossing the line
Three ways to go from user to supervisor mode:
Interrupts: HW device requests OS service- asynchronous
Traps: user program requests OS service (system call)–synchronous
Exceptions: user program acts silly (e.g. divide by zero)–synchronous
On Interrupts1. Driver tells disk controller
what to do by writing into device registers
CPUInterrupt
Controller
Disk
Controller
Diskdrive
On Interrupts1. Driver tells disk controller
what to do by writing into device registers
2. When it’s done, uses bus lines to signal interrupt controller chip
CPUDisk
Controller
Diskdrive
Interrupt
Controller
On Interrupts1. Driver tells disk controller
what to do by writing into device registers
2. When it’s done, uses bus lines to signal interrupt controller chip
3. Interrupt controller asserts pin on CPU to signal interrupt
CPUInterrupt
Controller
Disk
Controller
Diskdrive
On Interrupts1. Driver tells disk controller
what to do by writing into device registers
2. When it’s done, uses bus lines to signal interrupt controller chip
3. Interrupt controller asserts pin on CPU to signal interrupt
4. Interrupt controller puts device # on the bus for CPU to read
CPUInterrupt
Controller
Disk
Controller
Diskdrive
On InterruptsHardware calls OS at a pre-specified location by changing voltage on pins)
OS saves state of user program
OS identifies device and cause of interrupt
OS responds to the interrupt
OS restores state of the user program (if applicable) or some other user program
OS executes an RTI instruction to return to the user program
User program continues where it was interrupted.
Key Fact: None of this is visible to the user program
irq action
handlerflagsnamenext
Interrupt handling
routine for this device
0
1
2
3
4
5
6
7
8
9
Linux interrupt handling data structures
On ExceptionsHardware calls OS at a pre-specified location
OS identifies cause of exception (e.g. divide by 0)
If user program has exception handling specified, then OS adjusts user program state so that it calls its handler
Execute RTI 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
System callsProgramming interface to the services provided by the OS
Mostly accessed through an API (Application Programming Interface)
Win32, POSIX, Java API
Parameters passed inregisters
table (pointed by register)
stack
Example: Copying a fileAcquire input file name
Write prompt to screen
Accept input
Acquire output file name
Write prompt to screen
Accept input
Open the input file
If file does not exist, abort
Create output file
If file exists, abort
Loop
Read from input file
Write to output file
Until read fails
Close output file
Write completion message to screen
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!
User Program
system call interface
open()
i
open()implementation of open() system call...
return
On System Calls
User program executes a trap instruction (system call)
Hardware calls OS at a pre-specified location
OS identifies the required service and parameters (e.g. open(filename, O_RDONLY))
OS executes the required service
OS sets a register to contain the result of 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 function call executed under program control
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.
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 and can be invoked simultaneously by two different events (e.g. system call & an interrupt)
It is not supposed to terminate
It can execute any instruction in the machine
Summary Internal OS Structure
OS provides a more convenient interface than the raw hardware interface
The structure of the OS affects both the abstractions provided by the OS and their implementation
Monolithic structure (e.g. Unix)
Application Application Application Application
Everything
Hardware
Monolithic structure (e.g. Unix)
Application Application Application Application
API
Hardware
FileSystem
Memory Manager Process Manager NetworkSupport
Extensions & Add’l devicesDevice Drivers
Interrupt handlers
Boot & Init
Hardware Abstraction Layer
Protection
Advantages? !! ! ! Disadvantages?
Layered OS
Each system service is a layer
Each layer defines and implements an abstraction for the layer above it
Layers in effect “virtualize” the layer below
Advantages? Disadvantages? Hardware
Interrupt Handling,CPU Scheduling
Memory management (sees virtual processors)
Console and IPC(sees Virtual Memory)
Device buffers(sees a Virtual Console)
Users programs(see virtual I/O drivers)
THE System (EWD 1968)http://www.cs.utexas.edu/~EWD/ewd01xx/EWD196.PDF
Microkernels (e.g. Mach, Chorus)
Minimize kernel services, implement remaining OS modules as (protected) user level processes
Client/Server interaction, mediated by uniform message passing interface
Examples: Hydra (1970), MACH, Chorus, NT
Advantages? Disadvantages?
File SystemNetwork
Client (user) programs
Memory
Manager
Windowing
CPU Scheduling
Basic Message Passing
Device drivers Interrupt handlers
Boot & init
Hardware
OSmodules (servers)
Microkernel
...
Virtual Machine Monitors
Virtualize hardware to run multiple operating systems
Which part is “supervisor mode”?
What happens on a system call?
On an interrupt?Hardware
Virtual Machine Monitor
OS1 OS2 OS3 OS4
App 1
App 2
App 1
App 2
App 3
App 1 App 1
App 2
Awakening the Giant:System boot
What happens when you turn the power on?
1. CPU loads boot program from ROM
2.Boot program (BIOS in PCs):
Examines/checks machine configuration (number of CPU’s, how much memory, number & type of HW devices, etc.)Builds a configuration structure describing the hardwareLoads the bootloader
from “well-known” memory location (e.g. 1st sector of hard disk)to “well known” memory location (0x7c00 to 0x7dff in Bochs)
Jumps to bootloader code at “well-known” entry point
Awakening the Giant:The bootloader
3.Bootloader:
Initializes stuffSP = initial stack at well-known locationRead OS from disk, jump to well-known entry point
4.OS initialization
initialize kernel data structuresinitialize state of HW devicesinitialize VM systemcreates a number of processes to start operations (e.g. daemons tty in Unix, windowing system in NT): soon’ we’ll see how...
A sleepy Giant...
5.Once the OS is initializedRun user programs if available; else run low-priority user-level idle-process
In the idle processinfinite loop (Unix)system management and profilinghalt processor and enter low-power mode (notebooks)compute some function (DEC’s VAX VMS computed !)
OS wakes up oninterrupts from HW devicestraps from user programsexceptions from user programs
Processes
Getting to know youA process is a program during execution
Program = static file (image)
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
More to a process than just a program
I run ls, you run ls - same program- but different processes
Less to a process than a program
A program can invoke many processes to get the job done (e.g. cc starts up cpp, cc1, cc2, as–each a different process (and program!))
Keeping track of a process
A process has code
OS must track program counter
A process has a stack
OS must track stack pointer
OS stores state of processes’ computation in a process control block (PCB)
Data (program instructions, stack & heap) resides in memory, metadata is in PCB
Stack
Anatomy of a Process
Code
Header
Initialized data
Executable FileCode
Initialized data
Heap
DLL’s
mapped segments
Process’s
address space
PC
Stack Pointer
Registers
PID
UID
Priority
List of open files
…
Process Control
Block
A program consists of code and data
On running a program, the loader:
reads & interprets executable sets up the process’s memory to contain the code & data from executablepushes “argc”, “argv” on the stacksets the CPU registers properly & calls “__start()”
Program starts running at _start()
_start(args) {! ret = main(args);! exit(ret)}
When main() returns, OS calls “exit()” which destroys the process and returns all its resources
Running a program
Process Life Cycle
Processes are always either executing, waiting to
execute or waiting for an event to occur
NewProcess transitions from New to Ready when it becomes runnable
Process Life Cycle
Processes are always either executing, waiting to
execute or waiting for an event to occur
NewProcess transitions from New to Ready when it becomes runnable
Ready
Process Life Cycle
Processes are always either executing, waiting to
execute or waiting for an event to occur
Ready
NewProcess transitions from Ready to Running when kernel schedules it
Process Life Cycle
Processes are always either executing, waiting to
execute or waiting for an event to occur
Ready
StartProcess transitions from Ready to Running when kernel schedules it
Running
Process Life Cycle
Processes are always either executing, waiting to
execute or waiting for an event to occur
Ready
StartProcess transitions from Running to Waiting when they are blocked, waiting for an event to occur (e.g. I/O)Running
Process Life Cycle
Processes are always either executing, waiting to
execute or waiting for an event to occur
Ready
StartProcess transitions from Running to Waiting when they are blocked, waiting for an event to occur (e.g. I/O)Running
Waiting
Process Life Cycle
Processes are always either executing, waiting to
execute or waiting for an event to occur
Ready
StartProcess transitions from Waiting to Ready on an I/O or event completion
Running
Waiting
Process Life Cycle
Processes are always either executing, waiting to
execute or waiting for an event to occur
Ready
StartProcess transitions from Waiting to Ready on an I/O or event completion
Running
Waiting
Is that it?
Process Life Cycle
Processes are always either executing, waiting to
execute or waiting for an event to occur
Ready
Start
Running
Waiting
Process transitions from Running to Ready on an interrupt
Process Life Cycle
Processes are always either executing, waiting to
execute or waiting for an event to occur
Ready
Start
Running
Waiting
Process transitions from Running to Ready when scheduler picks another process (e.g. on a timer interrupt)
Process Life Cycle
Processes are always either executing, waiting to
execute or waiting for an event to occur
Ready
Start
Running
Waiting
Process transitions from Running to Done on exit()
Process Life Cycle
Processes are always either executing, waiting to
execute or waiting for an event to occur
Ready
Start
Running
Waiting
Process transitions from Running to Done on exit()Done
What happens on a read()?
Ready
Start
Running
Waiting
Done
