1 / 53

CPS110: Intro to (Operating) Systems

CPS110: Intro to (Operating) Systems. Author: Landon Cox Instructor: Jeff Chase August 24, 2009. Syllabus: prerequisites. CPS 100 Basic data structures and memory layout Allocating memory on the stack versus from the heap CPS 104 Basic computer architecture, ISAs

cdarden
Download Presentation

CPS110: Intro to (Operating) Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CPS110: Intro to (Operating) Systems Author: Landon Cox Instructor: Jeff Chase August 24, 2009

  2. Syllabus: prerequisites • CPS 100 • Basic data structures and memory layout • Allocating memory on the stack versus from the heap • CPS 104 • Basic computer architecture, ISAs • Registers: stack pointer, PC, general-purpose • Virtual memory translation • Page tables • TLB, caching • Other: C/C++

  3. Syllabus: lectures and textbook • Lecture notes on the web (125 pages) • Exams based on content of lectures • Textbooks • Only suggested • “Modern Operating Systems” • Easy to find on-line • New book: Saltzer and Kaashoek

  4. Syllabus: discussion sections • One section, starting this week • F 2:50 – 4:05 • Teaching Assistant • Jie Xiao (“Jennifer”) • (jiexiao@cs.duke.edu) • Undergraduate Teaching Assistants • Matt Jacobson

  5. Syllabus: homework problems • Posted on web on Monday of each week • Should be done before discussion section • Not graded, but count toward participation

  6. Syllabus: projects • Where you will learn the most • 4 projects • 0: very simple intro to C++ • 1: build a user-level concurrency package (thread library) • 2: build a virtual memory manager • 3: hack into a vulnerable system • Projects aren’t long, but are difficult (and “exacting”) • Only 100-1,000 lines/code, but could be many hours • Everything is in C++ • Project 0 will be posted in a few days

  7. Syllabus: project environment • Linux/GNU environment • You need a CS account • Don’t have one? Send me e-mail. • chase@cs.duke.edu by August 28 • Login to linux.cs.duke.edu to submit

  8. Syllabus: project groups • All projects done in groups of 2 or 3 • Email groups to chase@cs.duke.edu • By Friday (August 28) • {name, NetID, CS login} for each member • Group members may be asked to rate each other • Procedure for firing, quitting in syllabus

  9. Syllabus: project auto-grading • All projects are auto-graded • Immediate feedback • Use submit110 script on cs machines • One submission/group/day gets feedback • Can’t use to debug your project • + three bonus submissions/group/project • Any group member’s submission counts

  10. More on the auto-grader • Very narrow feedback: correct or incorrect • Doesn’t say what is wrong • Follow specifications carefully • Still have to write a test suite (except P0) • Don’t rely on auto-grader feedback alone • To get more useful feedback • Come talk to us! • We will provide many office hours every week • (double office hours week before a deadline)

  11. Syllabus: project timelines • Due at 6pm, accepted until 11:59:59pm • Auto-grader clock is the one that counts • Last submission to auto-grader is final • 3 late days/group/semester • Intended for unexpected problems • No extensions • Start early!

  12. Syllabus: project collaboration • Ok, among groups • C++ syntax, course concepts • “What does this part of the handout mean?” • Not ok, among groups • Design/writing of another’s program • Includes prior class solutions • “How do I do this part of the handout?” • We use automated similarity-detection software • Just changing the variable names won’t save you • http://theory.stanford.edu/~aiken/moss/ • If in doubt, ask me

  13. Syllabus: grades, exams • Projects: 35% • Midterm: 30% • Monday, February 23 • Final: 30% • Wednesday, April 29, 7-10pm • Participation: 5%

  14. Projects and exams • The two are not independent • Familiarity with projects is critical to doing well on exams • I like to ask questions about projects on exams • “Extend Project X to include this functionality” • Know your project! • You can assign roles to different people • But each member must understand all aspects

  15. Syllabus: getting help • Newsgroup • http://courses.duke.edu • Office hours • With me: Tu, 1:00 – 3:00, etc… • With Jie: Tu, 1:30 – 2:30, Th 4:00-5:00 • UTAs… • Post to the newsgroup • And you may also cc: us

  16. Questions about the course?

  17. Goals for CPS 110 • First part: demystify the operating system • How does my computer start running? • How does a program load into memory? • Second part: demystify the Internet • How does my email know where to go? • Why is Google so fast?

  18. Duke curriculum: one view Applications Ideas  high-level programming languages CPS 1,6,100,108 compiling, reading programs off disk, getting program into memory, reading keyboard, starting the computer, saving files, filenames, networking What’s missing? CPS 110 Hardware Assembly language program  gates CPS 104

  19. “Systems”: A Bigger Picture • Programmable platforms to enable sharing of data and resources • “Textbook” example: operating systems • “Cloud” clusters • Etc…?

  20. Systems as Art http://www.sammlung.daimler.com/sculpt/potsdamerplatz/potsd_tinguely500.jpg

  21. Thinking about interfaces • Consider the Java language and its key word “interface” • What is a Java object? • List of methods and collection of internal state • What is a Java interface? • Set of methods associated with an object that a programmer can call • What do those methods do? • Invoke code (let the object do work on the caller’s behalf) • Modify the object’s public/private state • Why are interfaces useful? • They provide an “abstraction” or simplification • Callers don’t have to know an object exact type or implementation

  22. OS terminology • Key terms: interface, resource (cpu, mem, etc), abstraction, virtual • What is an interface? • An interface is a set of primitives or operations • Interfaces provide access to resources and/or data • What do we mean by abstraction? • How resources are presented to a client • Can think of as an illusion that makes resources easier to program • What does it mean to virtualize something? • Provides an abstraction (simple way to manipulate resources) • (mostly) disallow direct access to reality/resources

  23. Interface and abstraction

  24. Virtualization?

  25. Standards, wrappers, adapters

  26. What is an operating system? • Program that runs on CPU, (mostly) like any other • Virtual interface should be “easier” than physical Applications “Virtual machine” Interface OS “Physical machine” Interface Hardware

  27. What is an operating system? Applications What interface does the OS present? “Virtual machine” Interface OS “Physical machine” Interface Hardware What interface does the hardware present? Instruction set: Load/store, mem, regs

  28. Hardware-software stack Applications System Calls Virtual Memory Threads Traps Page Tables Atomic Test/Set Files, Sockets Ether, 80211 OS Hardware

  29. OS vs user-level programs Alternate view Familiar view OS User program User program User program OS runs first, calls program Programs run until they return control to OS (by themselves or forced by hardware) Then OS calls another program How do programs start? Tasks outside program? (net recv) How do prevent CPU hogging? OS Who calls whom?

  30. Functions of the OS • Illusionist • Makes hardware seem “nicer” than it really is • Examples? • Programs seem to have their own CPU • AFS: single, unified file system • Name data with human-readable names • Directories • Packets get lost; OS makes net look reliable • Disk is slow; OS makes it look fast via caching

  31. Functions of the OS • Illusionist • Makes hardware seem nicer than it really is • Government • Divides hardware resources among competing programs • What hardware resources does the OS manage? • Processor • Memory • Network • Disk

  32. Functions of the OS • Illusionist • Makes hardware seem nicer than it really is • Government • Divides hardware resources among competing programs • Taxes programs (OS needs CPU, memory to run) • Taken for granted when it works, cursed when it breaks

  33. Why study operating systems? • Very few of you will ever write one … • Illusionist, govn functions appear in many domains • Google provides the illusion of a single web server • How should basketball seats be allocated? • Design principles • Proper abstractions, caching, indirection • Concurrency, naming, atomicity, authentication • Protection, resource multiplexing (fairness) • How does OS create the illusions we know/love?

  34. Hints for designing systems • What is a system? • Components, interconnections • Interfaces, environment • Systems do something for their environs • Export this behavior via an interface • Cleanly divides the world in two • Parts of the system + the environment

  35. Systems from 10,000 feet Component Component Component Component System Environment aka “the client”

  36. Why is designing systems hard? • Emergent properties • Can’t predict all component interactions • Millennium bridge • Synchronized stepping leads to swaying • Swaying leads to more forceful synchronized stepping • Leads to more swaying … • Propagation of effects • Incommensurate scaling • Trade-offs

  37. Why is designing systems hard? • Emergent properties • Propagation of effects • Want a better ride so increase the tire size • Need a larger trunk for the larger spare • Need to move the back seat forward • Need to make front seats thinner • Leads to worse driver comfort than before • Incommensurate scaling • Trade-offs

  38. Why is designing systems hard? • Emergent properties • Propagation of effects • Incommensurate scaling • Consider the giant mouse • Weight ~ size3 (volume) • Bone strength ~ size2 (cross section area) • An elephant sized mouse is not sustainable • Trade-offs

  39. Why is designing systems hard? • Emergent properties • Propagation of effects • Incommensurate scaling • Trade-offs • “Waterbed effect” • Push on one end, and the other goes up • Spam filters and smoke detectors • False positives vs false negatives

  40. Why is designing systems hard? • Emergent properties • Propagation of effects • Incommensurate scaling • Trade-offs • In the immortal words of HT Kung • “Systems hard. Must work harder.”

  41. History of operating systems • History dominated by two trends • Hardware: better, cheaper, faster • Software: sprawl • Microsoft embodies tension between these trends • MS gained 90% market share by running on cheap hw • Supporting all that hardware complicates the OS • (3rd-party drivers responsible for vast majority of crashes) • How is Apple’s strategy different? • Jobs chooses the hardware you will run • HW-to-app control reduces complexity, choice, discount

  42. First phase: single operator • One goal: make it work • Interactive (user has entire machine to herself) • Users sign up, get room for two hours at a time • “OS” is really just a library linked into your program What is wrong with this timeline? CPU utilization is awful Since CPUs were expensive, this mattered

  43. Second phase: batch processing • Goal: improve CPU, I/O utilization • Machine is no longer interactive • Users submit program (stack of cards) to queue • One job at a time, CPU idle during I/O, I/O idle during CPU • OS is a batch monitor + library of services • Loads program, runs program, prints results • Loads next program …

  44. Second phase: batch processing • Goal: improve CPU, I/O utilization • Machine is no longer interactive • Users submit program (stack of cards) to queue • One job at a time, CPU idle during I/O, I/O idle during CPU • What key OS function starts to matter now? • Protection: programs must not corrupt monitor • Programs must relinquish CPU to monitor

  45. Second phase: batch processing • Goal: improve CPU, I/O utilization • Machine is no longer interactive • Users submit program (stack of cards) to queue • One job at a time, CPU idle during I/O, I/O idle during CPU • Why wasn’t protection an issue before? • No batch monitor to corrupt • Person in lab coat took CPU back from program

  46. Third phase: multi-program batch • Goal: overlap CPU, I/O • When one job is reading from disk, run another job on CPU • Use DMA + interrupts to allow background I/O • DMA: devices write to program memory • Interrupts: devices can tell CPU the I/O is done Job 1 Job 2

  47. Third phase: multi-program batch • Goal: overlap CPU, I/O • What are the OS’s new responsibilities? • Switch between processes • Manage multiple I/Os across devices • Protect processes from each other Job 1 Job 2

  48. Fourth phase: time-sharing • Goal: keep efficiency, restore interactivity • Key insight: humans are really just slow I/O devices • Switch between programs during think-time Job 1 • Increased complexity: • Many jobs • Outstanding reqs • Many job sources Job 2 Job 3

  49. 4a: computing as a social medium JCR Licklider, “The Computer as a Communication Device” Science and Technology, April 1968.

  50. Fifth phase: personal computing • What are PC operating systems most like? • As PC prices dropped, single-operator became feasible • OS was again just a library of services (MS-DOS) • With one user, do jobs need to time-share? • Early PC OSes could only do one thing at a time • Everything waited while printing/loading a program (Mac < X) • Need protection if I’m the only one using the PC? • Protect me from myself (or my buggy software) • Early PCs provided no protection • (why Windows before XP, Mac before X were awful) • PC operating systems are basically time-sharing OSes now

More Related