DOC PREVIEW
Berkeley COMPSCI 162 - Lecture Notes

This preview shows page 1-2-3-4 out of 11 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

CS162Operating Systems andSystems ProgrammingLecture 1What is an Operating System?August 29, 2005Prof. John Kubiatowiczhttp://inst.eecs.berkeley.edu/~cs162Lec 1.28/29/05 Kubiatowicz CS162 ©UCB Fall 2005Who am I?• Professor John Kubiatowicz (Prof “Kubi”)– Background in Hardware Design» Alewife project at MIT» Designed CMMU, Modified SPAR C processor» Helped to write operating system– Background in Operating Systems» Worked for Project Athena (MIT) » OS Developer (device drivers, network file systems)» Worked on Clustered High-Availability systems(CLAM Associates)– Peer-to-Peer» OceanStore project –Store your data for 1000 years» Tapestry and Bamboo –Find you data around globe– Quantum Computing» Well, this is just cool, but probably not apropos Lec 1.38/29/05 Kubiatowicz CS162 ©UCB Fall 2005Goals for Today• What is an Operating System?– And – what is it not?• Examples of Operating Systems design• Why study Operating Systems?• Oh, and “How does this class operate?”Note: Some slides and/or pictures in the following areadapted from slides ©2005 Silberschatz, Galvin, and Gagne Lec 1.48/29/05 Kubiatowicz CS162 ©UCB Fall 2005Rapid Underlying Technology Change• “Cramming More Components onto Integrated Circuits”– Gordon Moore, Electronics, 1965Lec 1.58/29/05 Kubiatowicz CS162 ©UCB Fall 2005Computing Devices EverywhereLec 1.68/29/05 Kubiatowicz CS162 ©UCB Fall 2005Computer System Organization• Computer-system operation– One or more CPUs, device controllers connect through common bus providing access to shared memory– Concurrent execution of CPUs and devices competing for memory cyclesLec 1.78/29/05 Kubiatowicz CS162 ©UCB Fall 2005Functionality comes with great complexity!ProcCachesBussesMemoryI/O Devices:ControllersadaptersDisksDisplaysKeyboardsNetworksPentium III ChipsetLec 1.88/29/05 Kubiatowicz CS162 ©UCB Fall 2005Sample of Computer Architecture TopicsInstruction Set ArchitecturePipelining, Hazard Resolution,Superscalar, Reordering, Prediction, Speculation,Vector, Dynamic CompilationAddressing,Protection,Exception HandlingL1 CacheL2 CacheDRAMDisks, WORM, TapeCoherence,Bandwidth,LatencyEmerging TechnologiesInterleavingBus protocolsRAIDVLSIInput/Output and StorageMemoryHierarchyPipelining and Instruction Level ParallelismNetworkCommunicationOther ProcessorsLec 1.98/29/05 Kubiatowicz CS162 ©UCB Fall 2005Example: Some Mars Rover Requirements• Serious hardware limitations/complexity:– 20Mhz powerPC processor, 128MB of RAM – cameras, scientific instruments, batteries, solar panels, and locomotion equipment– Many independent processes work together• Can’t hit reset button very easily!– Must reboot itself if necessary– Always able to receive commands from Earth• Individual Programs must not interfere– Suppose the MUT (Martian Universal Translator Module) buggy– Better not crash antenna positioning software!• Further, all software may crash occasionally– Automatic restart with diagnostics sent to Earth– Periodic checkpoint of results saved?• Certain functions time critical:– Need to stop before hitting something– Must track orbit of Earth for communicationLec 1.108/29/05 Kubiatowicz CS162 ©UCB Fall 2005How do we tame complexity?• Every piece of computer hardware different– Different CPU» Pentium, PowerPC, ColdFire, ARM, MIPS– Different amounts of memory, disk, …– Different types of devices» Mice, Keyboards, Sensors, Cameras, Fingerprint readers– Different networking environment» Cable, DSL, Wireless, Firewalls,…• Questions:– Does the programmer need to write a single program that performs many independent activities?– Does every program have to be altered for every piece of hardware?– Does a faulty program crash everything?– Does every program have access to all hardware?Lec 1.118/29/05 Kubiatowicz CS162 ©UCB Fall 2005OS Tool: Virtual Machine Abstraction• Software Engineering Problem: – Turn hardware/software quirks ⇒what programmers want/need– Optimize for convenience, utilization, security, reliability, etc…• For Any OS area (e.g. file systems, virtual memory, networking, scheduling):– What’s the hardware interface? (physical reality)– What’s the application interface? (nicer abstraction)ApplicationOperating SystemHardwarePhysical Machine InterfaceVirtual Machine InterfaceLec 1.128/29/05 Kubiatowicz CS162 ©UCB Fall 2005Interfaces Provide Important Boundaries• Why do interfaces look the way that they do?– History, Functionality, Stupidity, Bugs, Management– CS152 ⇒ Machine interface– CS160 ⇒ Human interface• Should responsibilities be pushed across boundaries?– RISC architectures– Graphical Interfacesinstruction setsoftwarehardwareLec 1.138/29/05 Kubiatowicz CS162 ©UCB Fall 2005Virtual Machines• Software emulation of an abstract machine– Make it look like hardware has features you want– Programs from one hardware & OS on another one• Programming simplicity– Each process thinks it has all memory/CPU time– Each process thinks it owns all devices– Different Devices appear to have same interface– Device Interfaces more powerful than raw hardware» Bitmapped display ⇒ windowing system» Ethernet card ⇒ reliable, ordered, networking (TCP/IP)• Fault Isolation– Processes unable to directly impact other processes– Bugs cannot crash whole machine• Protection and Portability– Java interface safe and stable across many platformsLec 1.148/29/05 Kubiatowicz CS162 ©UCB Fall 2005Four Components of a Computer SystemDefinition: An operating system implements a virtual machine that is (hopefully) easier and safer to program and use than the raw hardware.Lec 1.158/29/05 Kubiatowicz CS162 ©UCB Fall 2005Virtual Machines (con’t): Layers of OSs• Useful for OS development– When OS crashes, restricted to one VM– Can aid testing programs on other OSsLec 1.168/29/05 Kubiatowicz CS162 ©UCB Fall 2005Nachos: Virtual OS Environment• You will be working with Nachos– Simulation environment– Hardware, interrupts, I/O– Execution of User Programs running on this platformLec 1.178/29/05 Kubiatowicz CS162 ©UCB Fall 2005What does an Operating System do?• Silerschatz and Gavin:“An OS is Similar to a government”– Begs the question: does a government do anything useful by itself?• Coordinator and Traffic Cop:– Manages all resources– Settles conflicting requests for resources– Prevent errors and improper


View Full Document

Berkeley COMPSCI 162 - Lecture Notes

Documents in this Course
Lecture 1

Lecture 1

12 pages

Nachos

Nachos

41 pages

Security

Security

39 pages

Load more
Download Lecture Notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture Notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture Notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?