cse 513 introduction to operating systems class 1...
TRANSCRIPT
CSE 513Introduction to Operating Systems
Class 1 - History and Intro toOS-related Hardware and Software
Jonathan WalpoleDept. of Comp. Sci. and Eng.
Oregon Health and Science University
About the Instructor & TA
q Instructor - Jonathan Walpolev Ph.D. Comp. Science. – Lancaster Uni., UK, 1987v Professor and Director of Systems Software Lab –
OGI (1998 -)v Research Interests: Operating System Design,
Distributed Computing Systems, MultimediaComputing and Networking
q TA - Chris Chambersv Ph.D. Student - Systems Software Lab, (2002-)v Research Interests: Distributed Games
About CSE 513
q Goals of the classv core class primarily for non-systems studentsv may be your first and last exposure to OSv understand the basic conceptsv gain some practical experience
q Expectationsv reading assignments should be read before classv active participation in class discussionsv no cheatingv be nice to the instructor and TA ;-)
Grading
q Examsv Mid-term - 20%v Final - 30%
q Courseworkv project - 30%
q Participationv in-class discussions - 20%
Books
Modern Operating Systems Understanding the Linux KernelA. Tannenbaum Daniel Bovet & Marco Cesati2nd Edition 2nd Edition
The Project
q We will be using Linux on real systems … ugh!!q The computer labs are equipped with Linux that
can be downloaded fresh when you turn them on+) You will be modifying a real O.S.+) It’s the real deal!-) More complicated than emulated systems-) Mistakes you make can cause catastrophic failure
à the blue screen of death will look friendlyq TA
v Chris Chambers will be the primary contact for theproject
Administrative
q Course web sitev http://www.cse.ogi.edu/class/cse513/
q Assignment 0v mail me a brief description of who you are, and a
picture of yourself … so I know who to assign creditto for your in-class discussion!
q Assignment 1v due next week! See class web site for project
assignments.
Lecture 1 - Introduction
Lecture overview
q What is an Operating System?
q A review of OS-related hardware
q History of operating systems
q Types of operating systems
What is an operating system?
q Operating system --“is a program that controlsthe execution of application programs and actsas an interface between the user of a computerand the computer hardware”v Narrow view
• Traditional computer with applications running on it(e.g. PCs, Workstations, Servers)
v Broad view• Anything that needs to manage resources (e.g.
router OS, embedded devices, pagers, ...)
Two Key OS Functions
q Abstract Machinev Hide details of the underlying hardwarev Provide “common” API to applications and servicesv Simplifies application writing
q Resource Managerv Controls accesses to “shared” resources
• CPU, memory, disks, network, ...v Allows for “global” policies to be implemented
Why is Abstraction Important?
q Without OSs and abstract interfaces application writersprogram all device access directlyv load device command codes into device registersv handle initialization, recalibration, sensing, timing etc for
physical devicesv understand physical characteristics and layoutv control motorsv interpret return codes … etc
q Applications suffer severe code bloat!v very complicated maintenance and upgradingv writing this code once, and sharing it, is how OS began!
Providing Abstraction via System Calls
OperatingSystem
Video CardCPU
Monitor PrinterDisk
MemoryNetwork
Application
Hardware
Providing Abstraction via System Calls
OperatingSystem
Video CardCPU
Monitor PrinterDisk
MemoryNetwork
Application
Hardware
System Calls: read(), open(), write(), mkdir(), kill() ...
Device MgmtFile System Network Comm.
Process Mgmt
Protection Security
OS as a Resource Manager
q Sharing resources among applications acrossspace and timev schedulingv allocation
q Making efficient use of limited resourcesv improving utilizationv minimizing overheadv improving throughput/good put
q Protecting applications from each otherv enforcement of boundaries
Problems an OS Must Solve
q Time sharing the CPU among applicationsq Space sharing the memory among applicationsq Space sharing the disk among usersq Time sharing access to the diskq Time sharing access to the network
More Problems an OS Must Solve
q Protectionv of applications from each otherv of user data from other usersv of hardware/devicesv of the OS itself!
q The OS needs help from the hardware toaccomplish these tasks!
Lecture overview
q What is an Operating System?
q A review of OS-related hardware
q History of operating systems
q Types of operating systems
Overview of computer system layers
Hardware - CPU, memory, I/O devices - disk, network ...
Basic anatomy on a CPU (1)
q Some key CPU Componentsv Program Counter (PC)
• holds memory address of next instructionv Instruction Register (IR)
• holds instruction currently being executedv Registers (Reg. 1..n)
• hold variables and temporary resultsv Arithmetic and Logic Unit (ALU)
• performs arithmetic functions and logic operations
Basic anatomy on a CPU (2)
q Some key CPU Componentsv Memory Address Register (MAR)
• contains address of memory to be read/writtenv Memory Data Register (MDR)
• contains memory data read or to be writtenv Stack Pointer (SP)
• holds memory address of stack with a frame foreach procedure’s local variables & parameters
v Processor Status Word (PSW)• contains the mode bit and various control bits
Program execution
q Instruction setsv different for different machinesv all have load and store instructions for moving items
between memory and registersv many instructions for comparing and combining
values in registers and putting result in a registerq Fetch/Decode/Execute cycle
v fetch next instruction pointed to by PCv decode it to find its type and operandsv execute itv repeat
Fetch/Decode/Execute Cycle
PC
MDR
IR
MAR
Reg. n
Reg. 1…
ALU
CPU Memory
Fetch/Decode/Execute Cycle
PC
MDR
IR
MAR
Reg. n
Reg. 1…
ALU
CPU Memory
While (1) { Fetch instruction from memory Execute instruction (Get other operands if necessary) Store result}
Fetch/Decode/Execute Cycle
PC
MDR
IR
MAR
Reg. n
Reg. 1…
ALU
CPU Memory
While (1) { Fetch instruction from memory Execute instruction (Get other operands if necessary) Store result}
Fetch/Decode/Execute Cycle
PC
MDR
IR
MAR
Reg. n
Reg. 1…
ALU
CPU Memory
While (1) { Fetch instruction from memory Execute instruction (Get other operands if necessary) Store result}
Fetch/Decode/Execute Cycle
PC
MDR
IR
MAR
Reg. n
Reg. 1…
ALU
CPU Memory
While (1) { Fetch instruction from memory Execute instruction (Get other operands if necessary) Store result}
Fetch/Decode/Execute Cycle
PC
MDR
IR
MAR
Reg. n
Reg. 1…
ALU
CPU Memory
While (1) { Fetch instruction from memory Execute instruction (Get other operands if necessary) Store result}
Fetch/Decode/Execute Cycle
PC
MDR
IR
MAR
Reg. n
Reg. 1…
ALU
CPU Memory
While (1) { Fetch instruction from memory Execute instruction (Get other operands if necessary) Store result}
The OS is just a program!
q How can the OS cause application programs torun?
q How can applications programs cause the OS torun?
q How can the OS switch the CPU to run adifferent application and later resume the firstone?
q How can the OS maintain control?q In what ways can application code try to cheat?q And how can the OS stop the cheating?
How Can the OS invoke an Application?
q The computer boots and begins running the OSv fetch/decode/execute OS instructions
q OS can request user input to identify anapplication to runv OS loads the address of the application’s starting
instruction into the PCv CPU fetches/decodes/executes the application’s
instructions
How Can Applications Invoke the OS?
q Trap instruction changes PC to point to an OSentry point instructionv application calls a library procedure that includes
the appropriate trap instructionv fetch/decode/execute cycle begins at a specified
OS entry point called a system call
How can the OS run a new Application?
q To suspend execution of an application simplycapture its memory state and processor statev copy values of all registers into a data structure
and save it to memoryv preserve the memory values of this application so it
can be restarted later
How can OS guarantee to regain control?
q What if a running application doesn’t make asystem call and hence hogs the CPU?v timer interrupts!v OS must register a future timer interrupt before it
hands control of the CPU over to an applicationq How can the OS avoid trampling on the
processor state it wants to save?v carefully written interrupt handlers!
What if the application tries to cheat?
q What stops the running application fromdisabling the future timer interrupt so that theOS can not regain control?v the mode bit (in the PSW)!
q Certain instructions can only be executed whenthe mode bit is setv manipulating timer interruptsv setting the mode bit!v ...
What other ways are there to cheat?
q What stops the running application frommodifying the OS?v Memory protection!v can only be set with mode bit set ….
q The OS must clear the mode bit before ithands control to an application!v interrupts and trap instructions set the mode bit
and transfer control to specific locations (in theOS)
Why its not quite that simple ...
q Pipelined CPUsq Superscalar CPUsq Multi-level memory hierarchiesq Virtual memoryq Complexity of devices and busesq Heterogeneity of hardware
Pipelined CPUs
Fetchunit
Decodeunit
Executeunit
Execution of current instruction performed in parallelwith decode of next instruction and fetch of the oneafter that
Superscalar CPUs
Fetchunit
Decodeunit
Executeunit
Fetchunit
Decodeunit
Executeunit
Executeunit
Holdingbuffer
What does this mean for the OS?
q Pipelined CPUsv more complexity in capturing state of a running
applicationv more expensive to suspend and resume applications
q Superscalar CPUsv even more complexity in capturing state of a running
applicationv even more expensive to suspend and resume
applications
q More details, but fundamentally the same task
The memory hierarchy
q 2GHz processor à 0.5 ns
q Data/inst. cache à 0.5ns – 10 ns, 64 kB- 1MB (this is where the CPU looks first!)
q Main memory à 60 ns, 512 MB – 1GB
q Magnetic disk à 10 ms, 160 Gbytes
q Tape à Longer than you want, less than magnetic disk!
Terminology review - metric units
The metric prefixes
The memory hierarchy
q 2GHz processor à 0.5 ns for access to a few 10s ofregisters
q Data/inst. cache à 0.5ns – 10 ns, 64 kB- 1MB (this is where the CPU looks first!)
q Main memory à 60 ns, 512 MB – 1GB
q Magnetic disk à 10 ms, 160 Gbytes
q Tape à Longer wait than you want, costs less than magnetic disk!
Who manages the memory hierarchy?
q Movement of data from main memory to cache is underhardware controlv cache lines loaded on demand automaticallyv replacement policy fixed by hardware
q Movement of data from cache to main memory can beaffected by OSv instructions for “flushing” the cachev can be used to maintain consistency of main memory
q Movement of data among lower levels of the memoryhierarchy is under direct control of the OSv virtual memory page faultsv file system calls
OS implications of a memory hierarchy?
q How do you keep the contents of memory consistentacross layers of the hierarchy?
q How do you allocate space at layers of the memoryhierarchy “fairly” across different applications?
q How do you hide the latency of the slower subsystems?• Main memory… yikes!• Disk• Tape
q How do you protect one application’s area of memoryfrom other applications?
q How do you relocate an application in memory?
Memory protection and relocation ...
q Memory protectionv virtual vs physical addresses
• address range in each application starts at 0v “base register” used to convert each virtual address to a
physical address before main memory is accessedv address is compared to a “limit register” to keep memory
references within bounds
q Relocationv by changing the base register value
q Paged virtual memoryv same basic concept, but more powerful (and complex)
Base & Limit Registers (single & multiple)
Virtual memory and MMUs
q Memory management unit (MMU)v hardware provided equivalent of base registersv at the granularity of “pages” of memory, say 2kB, i.e.,
lots of them!v supports relocation at page granularityv applications need not occupy contiguous physical memory
q Memory protectionv limit registers don’t work in this contextv per-page and per-application protection registers
q Relocation and protection occur at CPU speeds!
What about I/O devices?
Monitor
Bus
A simplified view of a computer system
Structure of a large Pentium system
What about I/O devices?
Monitor
Bus
A simplified view of a computer system
How do programs interact with devices?
q Devices vs device controllers vs device driversv device drivers are part of the OSv programs call the OS which calls the device driver
q Device drivers interact with device controllersv either using special IO instructionsv or by reading/writing controller registers that appear as
memory locations
q Why protect access to devices by accessing themindirectly via the OS?
How do devices interact with programs?
q Interrupts
Different types of interrupts
q Timer interruptsv Allows OS to maintain controlv One way to keep track of time
q I/O interruptsv Keyboard, mouse, disks, etc…
q Hardware failures
q Program generated (traps)v Programming errors: seg. faults, divide by zero, etc.v System calls like read(), write(), gettimeofday()
Timer interrupts
q OS can ask timer device to interrupt after a specifiedtime period has elapse
q Interrupt invokes timer interrupt handler which invokesOS “scheduler”
q OS can take the opportunity to save the currentapplication and restore a different onev context switch
Why use Traps for system calls?
q The Operating System is just a program!
q It must have the privilege to manipulate thehardwarev set base and limit registers for memory protectionv access devicesv set and clear mode bit to enable privilege
q If user programs execute with the mode bitclear, and do not have privilege to set it, howcan they invoke the OS so that it can run withthe mode bit set?v That’s what traps do … set the mode bit and begin
execution at a specific point in memory (in the OS!)
System calls
q System calls are the mechanism by whichprograms communicate with the O.S.
q Implemented via a TRAP instruction
q Example UNIX system calls:open(), read(), write(), close()kill(), signal()fork(), wait(), exec(), getpid()link(), unlink(), mount(), chdir()setuid(), getuid(), chown()
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
Steps in making a system call
What about disks and file storage?
Structure of a disk drive
Disks and file storage
q Manipulating the disk device is complicatedv hide some of the complexity behind disk controller,
disk device driver
q Disk blocks are not a very user-friendlyabstraction for storagev contiguous allocation may be difficult for large data
itemsv how do you manage administrative information?
q One application should not (automatically) beable to access another application’s storagev OS needs to provide a “file system”
File Systems
File system - an abstraction above disk blocks
What about networks?
q Network interfaces are just another kind ofshared device/resource
q Need to hide complexityv send and receive primitives, packets, interupts etcv protocol layers
q Need to protect the devicev access via the OS
q Need to allocate resources fairlyv packet scheduling
Lecture overview
q What is an Operating System?
q A review of OS-related hardware
q History of operating systems
q Types of operating systems
Brief history of OSs
q Vacuum tubes and plugboards (pre-1955)v “Man programs machine”v Machine à calculating hardware capable of only
number crunchingv Running programs
• Reserve machine time• Program it in machine language by physically
connecting wires!• Results printed on or punched in paper
v What was the OS?
Brief history of OSs
q Transistors and batch systems (1955-1965)v Human time really slow compared to processing capability,
hence staffs of professional operatorsv Batch systems à take a large number of jobs together,
run them sequentially, and output data to a tape forprinting
Brief history of OSs
q Transistors and batch systems (1955-1965)v A closer look at the batch system “OS”
• Load the next program into memory• Run it to its completion
– Output to tape when writes occur• When done, remove job
q What’s good?
q What’s bad?
q What is the OS?
Brief history of OSs
q ICs and multiprogramming – the beginnings of computingas we know it (1965-1980)v CPU “speed” vs. tape access tremendously differentv Great idea à Multiprogramming
• load all jobs in memory• run one job until it had to do I/O• switch to another job• repeat forever• use software to do the switching
v Another great idea à Time sharing systems• build terminals connected directly to the mainframe• run each job for a short time slice, rapidly switching
among jobs• supports interactive jobs doing lots of I/O
Brief history of OSs
q ICs and multiprogramming – the beginnings of computingas we know it (1965-1980)
v Requirements to support multiprogramming andtime-sharing
• 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 FIFO order)
q What is the OS?
Brief history of OSs
q Personal computers – (1980-present)v No sharingv Lots of different devices and configurationsv GUIs and interactivity
v Operating Systems• More user-centric
– Non-preemptable operating systems(e.g. Macintosh, Windows)
• Still required techniques from multiprogrammingand multitasking
Brief history of OSs
q Personal computers – (1980-present)v Reintroduced sharing - of data and peripheral
devices• Networking and Distributed Systems enable world
wide sharing of information and other resources
Computing technologies come full circle…
q Distributed heterogeneous systemsv Lots of heterogeneity (hardware/ data / programs)v Massively scalablyv Maintenance nightmare!
q Current trendsv IT out-sourcingv Centralized compute serversv Professional system management staff
Lecture overview
q What is an Operating System?
q A review of OS-related hardware
q History of operating systems
q Types of operating systems
The Operating System Zoo
q Mainframe operating systemsq Server operating systemsq Multiprocessor operating systemsq Personal computer operating systemsq Real-time operating systemsq Embedded operating systemsq Smart card operating systems
Ways of structuring operating systems
q Monolithicv All operating system functions are combined into a
single entity (address space & protection domain)
q Microkernelv Only key functionality in kernel. All other
functionality in user space modules thatcommunicate by message passing (no shared addressspace or protection domain)
q Virtual machinesv Give each user the illusion that they have their own
machine
“Structure” in a monolithic system
Structure in a strictly layered system
Structure of the THE operating system
Structure with virtual machines
Structure of VM/370 with CMS
Client-server structure in a micro-kernel OS
The client-server model
Distributed client-server structure
The client-server model in a distributed system
Summary
q Introductionq OS related hardwareq Historyq Operating system architectures
What to do before next week’s class
q Reading for today’s class - pages 1-70q Reading for next week’s class - pages 71-97 and
pages 132-152q Assignment 0 - send me a photo and short bioq Project assignment 1 - compile and run Linux OS
Review
How does the OS solve these problems?
q Time sharing the CPU among applicationsq Space sharing the memory among applicationsq Space sharing the disk among usersq Time sharing access to the diskq Time sharing access to the network
How does the OS solve these problems?
q Protectionv of applications from each otherv of user data from other usersv of hardware/devicesv of the OS itself!