Page 1 CS162 Operating Systems and Systems Programming Lecture 2 History of the World Parts 1—5 Operating Systems Structures January 21, 2010 Ion Stoica http://inst.eecs.berkeley.edu/~cs162 Lec 2.2 1/21/10 Ion Stoica CS162 ©UCB Spring 2010 Goals for Today • Operating Systems Structure • History of Operating Systems – Really a history of resource-driven choices • Operating Systems Organizations • Abstractions and layering Note: Some slides and/or pictures in the following are adapted from slides ©2005 Silberschatz, Galvin, and Gagne. Many slides generated from lecture notes by Joseph. Lec 2.3 1/21/10 Ion Stoica CS162 ©UCB Spring 2010 What if we didn’t have an Operating System? • Source Code⇒Compiler⇒Object Code⇒Hardware • How do you get object code onto the hardware? • How do you print out the answer? • Once upon a time, had to Toggle in program in binary and read out answer from LED’s! Altair 8080 Lec 2.4 1/21/10 Ion Stoica CS162 ©UCB Spring 2010 Simple OS: What if only one application? • Examples: – Very early computers – Early PCs – Embedded controllers (elevators, cars, etc) • OS becomes just a library of standard services – Standard device drivers – Interrupt handlers – Math librariesPage 2 Lec 2.5 1/21/10 Ion Stoica CS162 ©UCB Spring 2010 MS-DOS Layer Structure Lec 2.6 1/21/10 Ion Stoica CS162 ©UCB Spring 2010 More thoughts on Simple OS • What about Cell-phones, Xboxes, etc? – Is this organization enough? • Can OS be encoded in ROM/Flash ROM? • Does OS have to be software? – Can it be Hardware? – Custom Chip with predefined behavior – Are these even OSs? Lec 2.7 1/21/10 Ion Stoica CS162 ©UCB Spring 2010 More complex OS: Multiple Apps • Full Coordination and Protection – Manage interactions between different users – Multiple programs running simultaneously – Multiplex and protect Hardware Resources » CPU, Memory, I/O devices like disks, printers, etc • Facilitator – Still provides Standard libraries, facilities • Would this complexity make sense if there were only one application that you cared about? Lec 2.8 1/21/10 Ion Stoica CS162 ©UCB Spring 2010 Example: Protecting Processes from Each Other • Problem: Run multiple applications in such a way that they are protected from one another • Goal: – Keep User Programs from Crashing OS – Keep User Programs from Crashing each other – [Keep Parts of OS from crashing other parts?] • (Some of the required) Mechanisms: – Address Translation – Dual Mode Operation • Simple Policy: – Programs are not allowed to read/write memory of other Programs or of Operating SystemPage 3 Lec 2.9 1/21/10 Ion Stoica CS162 ©UCB Spring 2010 CPU MMU Virtual Addresses Physical Addresses Address Translation • Address Space – A group of memory addresses usable by something – Each program (process) and kernel has potentially different address spaces. • Address Translation: – Translate from Virtual Addresses (emitted by CPU) into Physical Addresses (of memory) – Mapping often performed in Hardware by Memory Management Unit (MMU) Lec 2.10 1/21/10 Ion Stoica CS162 ©UCB Spring 2010 Example of Address Translation Prog 1 Virtual Address Space 1 Prog 2 Virtual Address Space 2 Code Data Heap Stack Code Data Heap Stack Data 2 Stack 1 Heap 1 OS heap & Stacks Code 1 Stack 2 Data 1 Heap 2 Code 2 OS code OS data Translation Map 1 Translation Map 2 Physical Address Space Lec 2.11 1/21/10 Ion Stoica CS162 ©UCB Spring 2010 Dual Mode Operation • Hardware provides at least two modes: – “Kernel” mode (or “supervisor” or “protected”) – “User” mode: Normal programs executed • Some instructions/ops prohibited in user mode: – Example: cannot modify page tables in user mode » Attempt to modify ⇒ Exception generated • Transitions from user mode to kernel mode: – System Calls, Interrupts, Other exceptions Lec 2.12 1/21/10 Ion Stoica CS162 ©UCB Spring 2010 UNIX System Structure User Mode Kernel Mode Hardware Applications Standard LibsPage 4 Lec 2.13 1/21/10 Ion Stoica CS162 ©UCB Spring 2010 Moore’s Law Change Drives OS Change Typical academic computer 1981 vs 2009 0.2 $3,500 $25,000 ≤ 0.1 ≤ 1 10s 4 64 16 110,000 1 Gb/s 9600 b/s 150,000 1.5TB 10MB 49,152 6GB 128KB 1,280 6—40 Quad 3.2G 0.25—0.5 10 3—10 Factor 2009 1981 Price #users/machine # addr bits Net bandwidth Disk capacity DRAM capacity CPU MHz, Cycles/inst Lec 2.14 1/21/10 Ion Stoica CS162 ©UCB Spring 2010 Moore’s law effects • Nothing like this in any other area of business • Transportation in over 200 years: – 2 orders of magnitude from horseback @10mph to Concorde @1000mph – Computers do this every decade (at least until 2002)! • What does this mean for us? – Techniques have to vary over time to adapt to changing tradeoffs • Place a lot more emphasis on principles – The key concepts underlying computer systems – Less emphasis on facts that are likely to change over the next few years… • Let’s examine the way changes in $/MIP has radically changed how OS’s work Lec 2.15 1/21/10 Ion Stoica CS162 ©UCB Spring 2010 Administrivia • Waitlist: Everyone has been let into the class • Cs162-xx accounts: – Make sure you got an account form » We have more forms for those of you who didn’t get one – If you haven’t logged in yet, you need to do so • Nachos readers: – Will include lectures and printouts of all of the code • Video “Screencast” archives available off lectures page – Just click on the title of a lecture for webcast – Only works for lectures that I have already given! Lec 2.16 1/21/10 Ion Stoica CS162 ©UCB Spring 2010 Administriva: Time for Project Signup • 4-5 members to a group • All members of a group should be in same discussion section • If you want to change your discussion section, please send a request to: [email protected] – Request are not guaranteed to be accommodated, as we need to balance the section enrollment – Send your request by Monday, 1/25, 11:59 • Watch “Group/Section Assignment Link” for final assignments by Tuesday, 1/26 • Next, you’ll pick your group (we’ll tell you how to do
View Full Document