SLIDE 1 CSE 513 I ntroduction to Operating Systems Class 1 - History and I ntro to OS- related Hardware and Sof tware
Jonathan Walpole
- Dept. of Comp. Sci. and Eng.
Oregon Health and Science University
SLIDE 2 About the I nstructor & TA
I nstructor - Jonathan Walpole
P
h.D. Comp. Science. – Lancast er Uni., UK, 1987
P
rof essor and Direct or of Syst ems Sof t ware Lab – OGI (1998 -)
Research I nt erest s: Operat ing Syst em Design,
Dist ribut ed Comput ing Syst ems, Mult imedia Comput ing and Net working
TA - Chris Chambers
P
h.D. St udent - Syst ems Sof t ware Lab, (2002-)
Research I nt erest s: Dist ribut ed Games
SLIDE 3 About CSE 513
Goals of the class
core class primarily f or non-syst ems st udent s may be your f irst and last exposure t o OS underst and t he basic concept s gain some pract ical experience
Expectations
reading assignment s should be read bef ore class act ive part icipat ion in class discussions no cheat ing be nice t o t he inst ruct or and TA ;-)
SLIDE 4 Grading
Exams
Mid-t erm - 20% Final - 30%
Coursework
proj ect - 30%
Participation
in-class discussions - 20%
SLIDE 5 Books
Moder n Oper at ing Syst ems Under st anding t he Linux Ker nel
Daniel Bovet & Mar co Cesat i 2nd Edit ion 2nd Edit ion
SLIDE 6 The Project
We will be using Linux on real systems …
ugh!!
The computer labs are equipped with Linux that
can be downloaded f resh when you turn them on
+) You will be modif ying a real O. S. +) I t’s the real deal!
- ) More complicated than emulated systems
- ) Mistakes you make can cause catastrophic f ailure
the blue screen of death will look f riendly
TA
Chris Chambers will be t he primary cont act f or t he
proj ect
SLIDE 7 Administrative
Course web site
ht t p:/ / www.cse.ogi.edu/ class/ cse513/
Assignment 0
mail me a brief descript ion of who you are, and a
pict ure of yourself … so I know who t o assign credit t o f or your in-class discussion!
Assignment 1
due next week! See class web sit e f or proj ect
assignment s.
SLIDE 8
Lecture 1 - I ntroduction
SLIDE 9 Lecture overview
What is an Operating System? A review of OS- related hardware History of operating systems Types of operating systems
SLIDE 10 What is an operating system?
Operating system - - “is a program that controls
the execution of application programs and acts as an interf ace between the user of a computer and the computer hardware”
Narrow view
- Traditional computer with applications running on it
(e. g. PCs, Workstations, Servers)
Broad view
- Anything that needs to manage resources (e. g.
router OS, embedded devices, pagers, . . . )
SLIDE 11 Two Key OS Functions
Hide det ails of t he under lying har dwar e Pr ovide “common” API t o applicat ions and ser vices Simplif ies applicat ion wr it ing
Cont r ols accesses t o “shar ed” r esour ces
- CPU, memory, disks, network, . . .
Allows f or “global” policies t o be implement ed
SLIDE 12 Why is Abstraction I mportant?
- Without OSs and abstract interf aces application writers
program all device access directly
load device command codes int o device r egist er s handle init ializat ion, recalibrat ion, sensing, t iming et c f or
physical devices
under st and physical char act er ist ics and layout cont r ol mot or s int er pr et r et ur n codes …
et c
Applications suf f er severe code bloat!
ver y complicat ed maint enance and upgr ading wr it ing t his code once, and shar ing it , is how OS began!
SLIDE 13
Providing Abstraction via System Calls
Operating System Video Card CPU Monitor Printer Disk Memory Network Application Hardware
SLIDE 14
Providing Abstraction via System Calls
Operating System Video Card CPU Monitor Printer Disk Memory Network Application Hardware
System Calls: read(), open(), write(), mkdir(), kill() ... Device Mgmt File System Network Comm. Process Mgmt Protection Security
SLIDE 15 OS as a Resource Manager
Sharing resources among applications across
space and time
scheduling allocat ion
Making ef f icient use of limited resources
improving ut ilizat ion minimizing overhead improving t hroughput / good put
Protecting applications f rom each other
enf orcement of boundaries
SLIDE 16 Problems an OS Must Solve
Time sharing the CPU among applications Space sharing the memory among applications Space sharing the disk among users Time sharing access to the disk Time sharing access to the network
SLIDE 17 More Problems an OS Must Solve
Protection
- f applicat ions f rom each ot her
- f user dat a f rom ot her users
- f hardware/ devices
- f t he OS it self !
The OS needs help f rom the hardware to
accomplish these tasks!
SLIDE 18 Lecture overview
What is an Operating System? A review of OS- related hardware History of operating systems Types of operating systems
SLIDE 19
Overview of computer system layers
Hardware - CPU, memory, I/O devices - disk, network ...
SLIDE 20 Basic anatomy on a CPU (1)
Some key CPU Components
P
rogram Count er (P C)
- holds memory address of next instruction
I nst ruct ion Regist er (I R)
- holds instruction currently being executed
Regist ers (Reg. 1..n)
- hold variables and temporary results
Arit hmet ic and Logic Unit (ALU)
- perf orms arithmetic f unctions and logic operations
SLIDE 21 Basic anatomy on a CPU (2)
Some key CPU Components
Memory Address Regist er (MAR)
- contains address of memory to be read/ written
Memory Dat a Regist er (MDR)
- contains memory data read or to be written
St ack P
)
- holds memory address of stack with a f rame f or
each procedure’s local variables & parameters
Processor St at us Word (PSW)
- contains the mode bit and various control bits
SLIDE 22 Program execution
I nstruction sets
dif f erent f or dif f erent machines all have load and st ore inst ruct ions f or moving it ems
bet ween memory and regist ers
many inst ruct ions f or comparing and combining
values in regist ers and put t ing result in a regist er
Fetch/ Decode/ Execute cycle
f et ch next inst ruct ion point ed t o by P
C
decode it t o f ind it s t ype and operands execut e it repeat
SLIDE 23 Fetch/ Decode/ Execute Cycle
PC MDR IR MAR
… ALU CPU Memory
SLIDE 24 Fetch/ Decode/ Execute Cycle
PC MDR IR MAR
… ALU CPU Memory
While (1) { Fetch instruction from memory Execute instruction (Get other operands if necessary) Store result }
SLIDE 25 Fetch/ Decode/ Execute Cycle
PC MDR IR MAR
… ALU CPU Memory
While (1) { Fetch instruction from memory Execute instruction (Get other operands if necessary) Store result }
SLIDE 26 Fetch/ Decode/ Execute Cycle
PC MDR IR MAR
… ALU CPU Memory
While (1) { Fetch instruction from memory Execute instruction (Get other operands if necessary) Store result }
SLIDE 27 Fetch/ Decode/ Execute Cycle
PC MDR IR MAR
… ALU CPU Memory
While (1) { Fetch instruction from memory Execute instruction (Get other operands if necessary) Store result }
SLIDE 28 Fetch/ Decode/ Execute Cycle
PC MDR IR MAR
… ALU CPU Memory
While (1) { Fetch instruction from memory Execute instruction (Get other operands if necessary) Store result }
SLIDE 29 Fetch/ Decode/ Execute Cycle
PC MDR IR MAR
… ALU CPU Memory
While (1) { Fetch instruction from memory Execute instruction (Get other operands if necessary) Store result }
SLIDE 30 The OS is just a program!
How can the OS cause application programs to
run?
How can applications programs cause the OS to
run?
How can the OS switch the CPU to run a
dif f erent application and later resume the f irst
How can the OS maintain control? I n what ways can application code try to cheat? And how can the OS stop the cheating?
SLIDE 31 How Can the OS invoke an Application?
The computer boots and begins running the OS
f et ch/ decode/ execut e OS inst ruct ions
OS can request user input to identif y an
application to run
OS loads t he address of t he applicat ion’s st art ing
inst ruct ion int o t he P C
CP
U f et ches/ decodes/ execut es t he applicat ion’s inst ruct ions
SLIDE 32 How Can Applications I nvoke the OS?
Trap instruction changes PC to point to an OS
entry point instruction
applicat ion calls a library procedure t hat includes
t he appropriat e t rap inst ruct ion
f et ch/ decode/ execut e cycle begins at a specif ied
OS ent ry point called a syst em call
SLIDE 33 How can the OS run a new Application?
To suspend execution of an application simply
capture its memory state and processor state
copy values of all regist ers int o a dat a st ruct ure
and save it t o memory
preserve t he memory values of t his applicat ion so it
can be rest art ed lat er
SLIDE 34 How can OS guarantee to regain control?
What if a running application doesn’t make a
system call and hence hogs the CPU?
t imer int errupt s! OS must regist er a f ut ure t imer int errupt bef ore it
hands cont rol of t he CP U over t o an applicat ion
How can the OS avoid trampling on the
processor state it wants to save?
caref ully writ t en int errupt handlers!
SLIDE 35 What if the application tries to cheat?
What stops the running application f rom
disabling the f uture timer interrupt so that the OS can not regain control?
t he mode bit (in t he P
SW)!
Certain instructions can only be executed when
the mode bit is set
manipulat ing t imer int errupt s set t ing t he mode bit ! ...
SLIDE 36 What other ways are there to cheat?
What stops the running application f rom
modif ying the OS?
Memory prot ect ion! can only be set wit h mode bit set …
.
The OS must clear the mode bit bef ore it
hands control to an application!
int errupt s and t rap inst ruct ions set t he mode bit
and t ransf er cont rol t o specif ic locat ions (in t he OS)
SLIDE 37 Why its not quite that simple . . .
Pipelined CPUs Superscalar CPUs Multi- level memory hierarchies Virtual memory Complexity of devices and buses Heterogeneity of hardware
SLIDE 38
Pipelined CPUs
Fetch unit Decode unit Execute unit Execut ion of current inst ruct ion perf ormed in parallel wit h decode of next inst ruct ion and f et ch of t he one af t er t hat
SLIDE 39
Superscalar CPUs
Fetch unit Decode unit Execute unit Fetch unit Decode unit Execute unit Execute unit Holding buffer
SLIDE 40 What does this mean f or the OS?
Pipelined CPUs
more complexit y in capt uring st at e of a running
applicat ion
more expensive t o suspend and resume applicat ions
Superscalar CPUs
even more complexit y in capt uring st at e of a running
applicat ion
even more expensive t o suspend and resume
applicat ions
More details, but f undamentally the same task
SLIDE 41 The memory hierarchy
- 2GHz processor 0. 5 ns
- Data/ inst. cache 0. 5ns – 10 ns, 64 kB- 1MB
(this is where the CPU looks f irst!)
512 MB – 1GB
10 ms, 160 Gbytes
- Tape Longer than you want,
less than magnetic disk!
SLIDE 42
Terminology review - metric units
The met r ic pr ef ixes
SLIDE 43 The memory hierarchy
- 2GHz processor 0. 5 ns f or access to a f ew 10s of
registers
- Data/ inst. cache 0. 5ns – 10 ns, 64 kB- 1MB
(this is where the CPU looks f irst!)
512 MB – 1GB
10 ms, 160 Gbytes
- Tape Longer wait than you want,
costs less than magnetic disk!
SLIDE 44 Who manages the memory hierarchy?
- Movement of data f rom main memory to cache is under
hardware control
cache lines loaded on demand aut omat ically r eplacement policy f ixed by har dwar e
- Movement of data f rom cache to main memory can be
af f ected by OS
inst r uct ions f or “f lushing” t he cache can be used t o maint ain consist ency of main memor y
- Movement of data among lower levels of the memory
hierarchy is under direct control of the OS
vir t ual memor y page f ault s f ile syst em calls
SLIDE 45 OS implications of a memory hierarchy?
- How do you keep the contents of memory consistent
across layers of the hierarchy?
- How do you allocate space at layers of the memory
hierarchy “f airly” across dif f erent applications?
- How do you hide the latency of the slower subsystems?
- Main memory…
yikes!
- Disk
- Tape
- How do you protect one application’s area of memory
f rom other applications?
- How do you relocate an application in memory?
SLIDE 46 Memory protection and relocation . . .
vir t ual vs physical addr esses
- address range in each application starts at 0
“base r egist er ” used t o conver t each vir t ual addr ess t o a
physical addr ess bef or e main memor y is accessed
addr ess is compar ed t o a “limit r egist er ” t o keep memor y
r ef er ences wit hin bounds
by changing t he base r egist er value
same basic concept , but mor e power f ul (and complex)
SLIDE 47
Base & Limit Registers (single & multiple)
SLIDE 48 Virtual memory and MMUs
- Memory management unit (MMU)
har dwar e pr ovided equivalent of base r egist er s at t he gr anular it y of “pages” of memor y, say 2kB, i.e.,
lot s of t hem!
suppor t s r elocat ion at page gr anular it y applicat ions need not occupy cont iguous physical memor y
Memory protection
limit r egist er s don’t wor k in t his cont ext per -page and per -applicat ion pr ot ect ion r egist er s
Relocation and protection occur at CPU speeds!
SLIDE 49 What about I / O devices?
Monitor
Bus
A simplif ied view of a comput er syst em
SLIDE 50
Structure of a large Pentium system
SLIDE 51 What about I / O devices?
Monitor
Bus
A simplif ied view of a comput er syst em
SLIDE 52 How do programs interact with devices?
- Devices vs device controllers vs device drivers
device dr iver s ar e par t of t he OS pr ogr ams call t he OS which calls t he device dr iver
- Device drivers interact with device controllers
eit her using special I O inst r uct ions
- r by r eading/ wr it ing cont r oller r egist er s t hat appear as
memor y locat ions
- Why protect access to devices by accessing them
indirectly via the OS?
SLIDE 53 How do devices interact with programs?
SLIDE 54 Dif f erent types of interrupts
Timer interrupts
Allows OS t o maint ain cont rol One way t o keep t rack of t ime
I / O interrupts
Keyboard, mouse, disks, et c…
Hardware f ailures Program generated (traps)
P
rogramming errors: seg. f ault s, divide by zero, et c.
Syst em calls like read(), writ e(), get t imeof day()
SLIDE 55 Timer interrupts
- OS can ask timer device to interrupt af ter a specif ied
time period has elapse
- I nterrupt invokes timer interrupt handler which invokes
OS “scheduler”
- OS can take the opportunity to save the current
application and restore a dif f erent one
cont ext swit ch
SLIDE 56 Why use Traps f or system calls?
The Operating System is just a program! I t must have the privilege to manipulate the
hardware
set base and limit regist ers f or memory prot ect ion access devices set and clear mode bit t o enable privilege
I f user programs execute with the mode bit
clear, and do not have privilege to set it, how can they invoke the OS so that it can run with the mode bit set?
That ’s what t raps do …
set t he mode bit and begin execut ion at a specif ic point in memory (in t he OS!)
SLIDE 57 System calls
System calls are the mechanism by which
programs communicate with the O. S.
I mplemented via a TRAP instruction Example UNI X system calls:
- pen(), read(), write(), close()
kill(), signal() fork(), wait(), exec(), getpid() link(), unlink(), mount(), chdir() setuid(), getuid(), chown()
SLIDE 58 The inner workings of a system call
Process usercode { ... read (file, buffer, n); ... } Procedure read(file, buff, n) { ... read(file, buff, n) ... } _read: LOAD r1, @SP+2 LOAD r2, @SP+4 LOAD r3, @SP+6 TRAP Read_Call
User-level code Library code
SLIDE 59
Steps in making a system call
SLIDE 60
What about disks and f ile storage?
Structure of a disk drive
SLIDE 61 Disks and f ile storage
Manipulating the disk device is complicated
hide some of t he complexit y behind disk cont roller,
disk device driver
Disk blocks are not a very user- f riendly
abstraction f or storage
cont iguous allocat ion may be dif f icult f or large dat a
it ems
how do you manage administ rat ive inf ormat ion?
One application should not (automatically) be
able to access another application’s storage
OS needs t o provide a “f ile syst em”
SLIDE 62
File Systems
File system - an abstraction above disk blocks
SLIDE 63 What about networks?
Network interf aces are just another kind of
shared device/ resource
Need to hide complexity
send and receive primit ives, packet s, int erupt s et c prot ocol layers
Need to protect the device
access via t he OS
Need to allocate resources f airly
packet scheduling
SLIDE 64 Lecture overview
What is an Operating System? A review of OS- related hardware History of operating systems Types of operating systems
SLIDE 65 Brief history of OSs
Vacuum tubes and plugboards (pre- 1955)
“Man programs machine” Machine calculat ing hardware capable of only
number crunching
Running programs
- Reserve machine time
- Program it in machine language by physically
connecting wires!
- Results printed on or punched in paper
What was t he OS?
SLIDE 66 Brief history of OSs
- Transistors and batch systems (1955- 1965)
Human t ime r eally slow compar ed t o pr ocessing capabilit y,
hence st af f s of pr of essional oper at or s
Bat ch syst ems t ake a lar ge number of j obs t oget her ,
r un t hem sequent ially, and out put dat a t o a t ape f or print ing
SLIDE 67 Brief history of OSs
- Transistors and batch systems (1955- 1965)
A closer look at t he bat ch syst em “OS”
- Load the next program into memory
- Run it to its completion
– Output to tape when writes occur
- When done, remove job
- What’s good?
- What’s bad?
- What is the OS?
SLIDE 68 Brief history of OSs
- I Cs and multiprogramming – the beginnings of computing
as we know it (1965- 1980)
CPU “speed” vs. t ape access t r emendously dif f er ent Gr eat idea Mult iprogramming
- load all jobs in memory
- run one job until it had to do I / O
- switch to another job
- repeat f orever
- use sof tware to do the switching
Anot her gr eat idea Time shar ing syst ems
- build terminals connected directly to the mainf rame
- run each job f or a short time slice, rapidly switching
among jobs
- supports interactive jobs doing lots of I / O
SLIDE 69 Brief history of OSs
- I Cs and multiprogramming – the beginnings of computing
as we know it (1965- 1980)
Requir ement s t o suppor t mult ipr ogr amming and
t ime-shar ing
- Ability to “save” a running task (MT)
- Ability to manage devices
- Ability to partition memory among processes
- Ability to protect memory
- Ability to prioritize and select tasks to run
(in non FI FO order)
SLIDE 70 Brief history of OSs
Personal computers – (1980- present)
No sharing Lot s of dif f erent devices and conf igurat ions GUI s and int eract ivit y Operat ing Syst ems
– Non- preemptable operating systems (e. g. Macintosh, Windows)
- Still required techniques f rom multiprogramming
and multitasking
SLIDE 71 Brief history of OSs
Personal computers – (1980- present)
Reint roduced sharing - of dat a and peripheral
devices
- Networking and Distributed Systems enable world
wide sharing of inf ormation and other resources
SLIDE 72 Computing technologies come f ull circle…
Distributed heterogeneous systems
Lot s of het erogeneit y (hardware/ dat a / programs) Massively scalably Maint enance night mare!
Current trends
I T out -sourcing Cent ralized comput e servers P
rof essional syst em management st af f
SLIDE 73 Lecture overview
What is an Operating System? A review of OS- related hardware History of operating systems Types of operating systems
SLIDE 74 The Operating System Zoo
Mainf rame operating systems Server operating systems Multiprocessor operating systems Personal computer operating systems Real- time operating systems Embedded operating systems Smart card operating systems
SLIDE 75 Ways of structuring operating systems
Monolithic
All operat ing syst em f unct ions are combined int o a
single ent it y (address space & prot ect ion domain)
Microkernel
Only key f unct ionalit y in kernel. All ot her
f unct ionalit y in user space modules t hat communicat e by message passing (no shared address space or prot ect ion domain)
Virtual machines
Give each user t he illusion t hat t hey have t heir own
machine
SLIDE 76
“Structure” in a monolithic system
SLIDE 77
Structure in a strictly layered system
Structure of the THE operating system
SLIDE 78
Structure with virtual machines
Structure of VM/ 370 with CMS
SLIDE 79
Client- server structure in a micro- kernel OS
The client- server model
SLIDE 80
Distributed client- server structure
The client- server model in a distributed system
SLIDE 81 Summary
I ntroduction OS related hardware History Operating system architectures
SLIDE 82 What to do bef ore next week’s class
Reading f or today’s class - pages 1- 70 Reading f or next week’s class - pages 71- 97 and
pages 132- 152
Assignment 0 - send me a photo and short bio Project assignment 1 - compile and run Linux OS
SLIDE 83
Review
SLIDE 84 How does the OS solve these problems?
Time sharing the CPU among applications Space sharing the memory among applications Space sharing the disk among users Time sharing access to the disk Time sharing access to the network
SLIDE 85 How does the OS solve these problems?
Protection
- f applicat ions f rom each ot her
- f user dat a f rom ot her users
- f hardware/ devices
- f t he OS it self !
