操作系统的基本概念

1 . Who am I? • Professor John Kubiatowicz (Prof “Kubi”) CS194-24 – Background in Hardware Design Alewife » Alewife project at MIT Advanced Operating Systems » Designed CMMU, Modified SPAR C processor Structures and Implementation » Helped to write operating system – Background in Operating Systems Lecture 1 » Worked for Project Athena (MIT) » OS Developer (device drivers, Tessellation network file systems) What is an Operating System? » Worked on Clustered High-Availability systems (CLAM Associates) » OS lead researcher for the Berkeley PARLab (Tessellation OS). More later. January 22rd, 2014 » OS lead for new SwarmLAB as well Prof. John Kubiatowicz – Peer-to-Peer http://inst.eecs.berkeley.edu/~cs194-24 » OceanStore project – OceanStore Store your data for 1000 years » Tapestry and Bamboo – Find you data around globe – Quantum Computing 1/22/14 » Well, this is just cool, but Kubiatowicz probably CS194-24 not ©UCB Fallapropos 2014 Lec 1.2 Goals for Today Technology Trends: Moore’s Law • Why is writing an OS Interesting and Difficult? • Class Format and Administrivia • Why study Operating Systems? Interactive is important! Moore’s Law Ask Questions! 2X transistors/Chip Every 1.5 years Called “Moore’s Law” Gordon Moore (co-founder of Intel) predicted in 1965 that the Note: Some slides and/or pictures in the following are Microprocessors have adapted from slides ©2013 Silberschatz, Galvin, and Gagne. Slides transistor density of courtesy of Kubiatowicz, AJ Shankar, George Necula, Alex Aiken, semiconductor chips would become smaller, denser, Eric Brewer, Ras Bodik, Ion Stoica, Doug Tygar, and David Wagner. double roughly every 18 and more powerful. months. 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.3 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.4 

2 . Societal Scale Information Systems People-to-Computer Ratio Over Time • The world is a large parallel system – Microprocessors in everything Massive Cluster From David Culler – Vast infrastructure behind them Gigabit Ethernet Clusters Internet Scalable, Reliable, Connectivity Secure Services Databases Information Collection Remote Storage Online Games Commerce … • Today: Multiple CPUs/person! MEMS for – Approaching 100s? Sensor Nets 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.5 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.6 New Challenge: Slowdown in Joy’s law of Performance ManyCore Chips: The future is here • Intel 80-core multicore chip (Feb 2007) 10000 3X – 80 simple cores From Hennessy and Patterson, Computer Architecture: A Quantitative Approach, 4th edition, Sept. 15, 2006 – Two FP-engines / core ??%/year – Mesh-like network – 100 million transistors 1000 – 65nm feature size Performance (vs. VAX-11/780) • Intel Single-Chip Cloud 52%/year Computer (August 2010) 100 – 24 “tiles” with two cores/tile – 24-router mesh network – 4 DDR3 memory controllers  Sea change in chip – Hardware support for message-passing 10 25%/year design: multiple “cores” or • “ManyCore” refers to many processors/chip processors per chip – 64? 128? Hard to say exact boundary 1 • How to program these? 1978 1980 1982 1984 1986 1988 1990 1992 1994 1996 1998 2000 2002 2004 2006 – Use 2 CPUs for video/audio • VAX : 25%/year 1978 to 1986 – Use 1 for word processor, 1 for browser • RISC + x86: 52%/year 1986 to 2002 – 76 for virus checking??? • RISC + x86: ??%/year 2002 to present • Parallelism must be exploited at all levels 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.7 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.8 

3 . Another Challenge: Power Density Computer 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 cycles • Moore’s Law Extrapolation – Potential power density reaching amazing levels! • Flip side: Battery life very important – Moore’s law can yield more functionality at equivalent (or less) total energy consumption 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.9 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.10 Chip-scale features of SandyBridge SandyBridge I/O: PCH • Significant pieces: • Platform Controller Hub – Four OOO cores – Used to be » New Advanced Vector eXtensions (256-bit “SouthBridge,” but no FP) “NorthBridge” now » AES instructions – Connected to processor » Instructions to help with Galois-Field mult with proprietary bus » 4 -ops/cycle » Direct Media Interface – Integrated GPU – Code name “Cougar – System Agent (Memory and Fast I/O) Point” for SandyBridge – Shared L3 cache divided in 4 banks processors – On-chip Ring bus network • Types of I/O on PCH: » Both coherent and non-coherent transactions – USB » High-BW access to L3 Cache – Ethernet • Integrated I/O – Audio – Integrated memory controller (IMC) – BIOS support » Two independent channels of DDR3 DRAM – More PCI Express (lower SandyBridge speed than on Processor) – High-speed PCI-Express (for Graphics cards) – DMI Connection to SouthBridge (PCH) System Configuration – Sata (for Disks) 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.11 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.12 

4 . Sample of Computer Architecture Topics Storage Capacity Input/Output and Storage Disks, WORM, Tape RAID Emerging Technologies DRAM Interleaving Bus protocols Coherence, Memory L2 Cache Bandwidth, Other Processors Hierarchy Latency Network Communication L1 Cache Addressing, VLSI Protection, Instruction Set Architecture Exception Handling Pipelining, Hazard Resolution, Pipelining and Instruction Superscalar, Reordering, Level Parallelism Prediction, Speculation, • Hard disk capacity (in GB) (source: Vector, Dynamic Compilation http://www.digitaltonto.com/2011/our-emergent-digital-future/) 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.13 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.14 Network Capacity Increasing Software Complexity From MIT’s 6.033 course (source: http://www.ospmag.com/issue/article/Time-Is-Not-Always-On-Our-Side) 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.15 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.16 

5 . How do we tame complexity? OS Tool: Virtual Machine Abstraction • Every piece of computer hardware different Application – Different CPU Virtual Machine Interface » Pentium, PowerPC, ColdFire, ARM, MIPS – Different amounts of memory, disk, … Operating System – Different types of devices Physical Machine Interface » Mice, Keyboards, Sensors, Cameras, Fingerprint Hardware readers – Different networking environment • Software Engineering Problem: » Cable, DSL, Wireless, Firewalls,… – Turn hardware/software quirks  what programmers want/need • Questions: – Optimize for convenience, utilization, security, – Does the programmer need to write a single program reliability, etc… that performs many independent activities? • For Any OS area (e.g. file systems, virtual memory, – Does every program have to be altered for every networking, scheduling): piece of hardware? – What’s the hardware interface? (physical reality) – Does a faulty program crash everything? – What’s the application interface? (nicer abstraction) – Does every program have access to all hardware? 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.17 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.18 Interfaces Provide Important Boundaries Virtual Machines • Software emulation of an abstract machine software – Make it look like hardware has features you want – Programs from one hardware & OS on another one instruction set • Programming simplicity – Each process thinks it has all memory/CPU time hardware – 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 • Why do interfaces look the way that they do? » Ethernet card  reliable, ordered, networking (TCP/IP) – History, Functionality, Stupidity, Bugs, Management • Fault Isolation – CS152  Machine interface – Processes unable to directly impact other processes – CS160  Human interface – Bugs cannot crash whole machine – CS169  Software engineering/management • Protection and Portability – Stability of POSIX interface between systems • Should responsibilities be pushed across boundaries? – Limits to what Users programs are allowed to do – RISC architectures, Graphical Pipeline Architectures 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.19 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.20 

6 . Virtual Machines (con’t): Layers of OSs Course Administration • Useful for OS development • Instructor: John Kubiatowicz (kubitron@cs.berkeley.edu) – When OS crashes, restricted to one VM 673 Soda Hall Office Hours(Tentative): M/W 4:00-5:00pm – Can aid testing programs on other OSs • TA(2): Vedant Kumar, Palmer Dabbelt • Labs: Mostly on your own Laptops (secondarily?) Second floor of Soda Hall • Website: http://cs194-24.cs.berkeley.edu Mirror: http://www.cs.berkeley.edu/~kubitron/cs194-24 • Redmine: https://cs194-24.cs.berkley.edu/redmine • Webcast: Yes(?). Details to follow… • Newsgroup: We are using Piazza this term. • Course Email: cs194-24@cory.cs.berkeley.edu 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.21 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.22 Class Schedule Textbooks – Many! • Class Time: M/W 2:30-4:00, 306 Soda Hall • We will be using a number of different books – Please come to class. Lecture notes do not have everything in them. The best part of class is the interaction! – Hard to find any one text that has everything we want – Also: 10% of the grade is from class participation (section – In fact, will event be supplementing with research papers! and class) • Sections: – Important information is in the sections • Sources for these books: All electronic? – Every member of a project group must be in same section – On Information page of website, I’ve highlighted sources for each of the books – Go to either section this week and next (until groups are assigned) » Consider electronic versions from Amazon and the Pragmatic Programmer for first three books (with PC/Mac Kindle app) » Use Safari-Online for remaining books (all O’Reilly books available this way) Section Time Location TA 101 F 3:00pm-4:00 pm 405 Soda Palmer Dabbelt – Alternatively, first three books should be available from the Berkeley Bookstore 102 F 4:00pm-5:00pm 405 Soda Palmer Dabbelt (New!) 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.23 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.24 

7 . Textbooks Textbooks (con’t) • Text #1: Linux Kernel Development • Text #3: Operating Systems Concepts, 9th Edition, 3rd Edition, Robert Love Silbershatz, Galvin, Gagne • Text on the structure of Linux 2.6.xx Kernel • Yes, you used this in CS162, but we will be Discusses Practical Aspects of implementation covering some aspects in more depth • Need 3rd Edition? Yes! 2.6 Kernel • Online supplements • Best Source: Amazon Kindle version? – See “Information” link on course website Kindle app for PC or MAC is quite good – Includes Appendices, sample problems, etc • Best source for book: Amazon Kindle version? • Text #2: The Cucumber Book – Can also RENT ebook for period of time Matt Wynne and Aslak Hellesøy • Question: need 9th edition? • Text on the Cucumber Language for testing. – No, but has new material that we will cover We will be using Test-Driven Development for our laboratory projects – Especially sections on Virtual Machines • Best Source: Directly from Publisher? – If already have 8th edition, could Can get ebook version – Directly load into Kindle potentially rent 9th edition for end of term Application 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.25 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.26 Textbook (Supplemental) Available online on Berkeley Campus Topic Coverage • Text #4: Understanding the Linux Kernel 1.5 weeks: Fundamentals (Operating Systems Structures), 3rd Edition, Testing, and Linux Structure Daniel P. Bovet, Marco Cesati • 0.5 weeks: x86 Architecture Available from Safari-Online, Link on Homepage • 2 weeks: Processes, Synchronization, and Scheduling • 1.5 weeks: File Systems, VFS, and Distributed Storage • Text #5: Linux Device Drivers • 1 week: Memory Management/Demand Paging 3rd Edition, • 1.5 weeks: I/O and Device Drivers Structure Jonathan Corbet, Alessandro Rubini, • 1.5 weeks: Networking Subsystem Greg Kroah-Hartman Available from Safari-Online, Link on Homepage • 1.5 week: Protection and Security • 1 week: Virtual Machines • Text #6: Understanding Linux Network Internals • ??: Advanced topics 1st Edition, Christian Benvenuti Available from Safari-Online, Link on Homepage 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.27 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.28 

8 . Group Project Simulates Industrial Environment Tentative Project Schedule • Project teams have 4 or 5 members in same • Five Projects: Still under development discussion section – Project 0: Getting Started (Done Individually) – Must work in groups in “the real world” – Project 1: Web Browser with QoS • Communicate with colleagues (team members) – Project 2: Secure/CopyOnWrite File System – Communication problems are natural – Project 3: Realtime Scheduler – Project 4: Network Device Driver – What have you done? – What answers you need from others? • Contest at end – all pieces running together – You must document your work!!! – Who will have the fastest/most functional system? – Everyone must keep an on-line notebook – Still working out details • Communicate with supervisor (TAs) – How is the team’s plan? – Short progress reports are required: » What is the team’s game plan? » What is each member’s responsibility? 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.29 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.30 Grading Academic Dishonesty Policy • Copying all or part of another person's work, or using reference • Rough Grade Breakdown material not specifically allowed, are forms of cheating and will – One Midterm: 25% each (Perhaps 2?) not be tolerated. A student involved in an incident of cheating will One Final: 25% be notified by the instructor and the following policy will apply: Five Projects: 45% (5%, 10%, 10%, 10%, 10%) http://www.eecs.berkeley.edu/Policies/acad.dis.shtml Participation: 5% • The instructor may take actions such as: • Late Policy: – require repetition of the subject work, – Each group has 5 “slip” days. – assign an F grade or a 'zero' grade to the subject work, » Slip Days only for Code/Final Document, NOT design – for serious offenses, assign an F grade for the course. – For Projects, slip days deducted from all partners • The instructor must inform the student and the Department Chair – 10% off per day after slip days exhausted in writing of the incident, the action taken, if any, and the student's right to appeal to the Chair of the Department Grievance Committee or to the Director of the Office of Student Conduct. • The Office of Student Conduct may choose to conduct a formal hearing on the incident and to assess a penalty for misconduct. • The Department will recommend that students involved in a second incident of cheating be dismissed from the University. 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.31 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.32 

9 . Please Do NOT Typical Lecture Format • As you may know, over 25% caught cheating last term in 162 – We will assume you are more mature than the 162 crowd • Please Do NOT Use solutions/sources from GitHUB Attention – These will be out of date anyway – We know about any existing ones and will be watching for 20 min. Break 25 min. Break 25 min. “In Conclusion, ...” plagiarism • Please Do NOT Use solutions/sources from other groups or Time elsewhere • 1-Minute Review – We are going to be running MOSS • 20-Minute Lecture – We are going to be meeting with you regularly to ask you about • 5- Minute Administrative Matters functionality • 25-Minute Lecture • Finally: Please Do NOT Upload solutions/sources to GitHUB • 5-Minute Break (water, stretch) – This will probably contribute to the cancellation of this class for • 25-Minute Lecture the future… • Instructor will come to class early & stay after to answer questions 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.33 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.34 Lecture Goal How to work on OSes easily? • Traditional: – Sit at serial console, – Upload new OS image somehow – Reboot and possibly crash (“Panic”) – Debug with very limited tools • How we will do it in this class: Virtual Machines! Interactive!!! • In fact – Nested Virtual Machines: VMware KVM OS Under Test Virtual Machine Virtual Machine (Experimental) Linux Development Environment 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.35 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.36 

10 . Behavior-Driven Development Computing Facilities • We are going to use a Behavior-Driven Development • This class is best taken with a late-model laptop process for our projects. According to Wikipedia: – Looking for an x86 with Vt-x extensions – “Behavior-driven development combines the general techniques and principles of Test-Driven Development (TDD) with ideas – Will be working in a VMWare virtual machine from domain-driven design and object-oriented analysis and – Should be able to use Windows, Mac-OS, or Linux design to provide software developers and business analysts with shared tools and a shared process to collaborate on • Machines in 277 Soda are also available software development,with the aim of delivering ‘software that matters’ ". – However, use of these machines more difficult – “Test-driven development (TDD) is a software development – Not quite configured process that relies on the repetition of a very short • Also, should have a USB key with 8GB storage development cycle: » first the developer writes an (initially failing) automated test – Will be building a bootable image later in term case that defines a desired improvement or new function, • Every student who is enrolled should get an » then produces the minimum amount of code to pass that account form at end of lecture test, and » finally refactors the new code to acceptable standards. “ – Gives you an account of form cs162-xx@cory • We are going to be writing Behaviors in Cucumber as well – This account gives you access to Instructional Tests in a variety of unit-testing frameworks. machines as well as VMWare licenses! 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.37 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.38 Course Resources Course Resources (Continued) • “Laboratory” Link has important information about • Development via git repositories projects. Need to start “Project 0” immediately! – Every student gets private Redmine “Project” with – Go to VMWare website to get 30-day license for either associated repository. Think of this as your personal VMWare Workstation (Windows or Linux) or storage. Use for Project 0/0.5 and your own work later VMWare Fusion (Apple MAC). – Every Group will get Redmine “Project” and git repo to do » Course Licenses Projects 1-4. – Virtual Machine image off “Laboratory” link in .zip form • Redmine also has facilities for Bug tracking » Should probably go down to 277 Soda and make hard-link connection when downloading (1.6 GB even compressed!) – Will post bugs and resolutions for Labs as neces • Redmine project development site – Will be encouraging you to use these facilities for intra- group communication – We are using a Redmine project development site for all resource control, bug tracking, etc – Also has Forums which can be used for intra-group communication – Your CalNet/GoogleDOCS account gives you access • Piazza site for course announcements and » Log in by clicking on the “Google” icon on the main screen Student/Staff communication » Log in right away and update your name/email – I’ve entered everyone’s email as of this morning (so that » Generate an ssh key and upload that to the server it will send out invitations) » Remote access to git repositories. – Please respond to invitations and/or sign up yourself 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.39 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.40 

11 . Why are we working on Linux? What does an Operating System do? • Penetration into many markets: • Silerschatz and Gavin: – Embedded space “An OS is Similar to a government” » Phones, Routers, Sensors – Begs the question: does a government do anything useful by – Desktops itself? » Gnome, KDE, other X environments • Coordinator and Traffic Cop: – Servers – Manages all resources » High-end cloud services, Web services, File services – Settles conflicting requests for resources • Open-source! – Prevent errors and improper use of the computer – Can learn by “reading the source!” • Facilitator: • Extreme team-collaborative environment – Provides facilities that everyone needs – Native use of development tools like “git”, “gdb”, lots of – Standard Libraries, Windowing systems testing and development tools – Linux started the “Bizzare” method of development – Make application programming easier, faster, less error-prone • Negatives? • Some features reflect both tasks: – Code not always well-designed – E.g. File system is needed by everyone (Facilitator) – No central authority enforcing “quality” – But File system must be Protected (Traffic Cop) – Occasionally versions of different components “out-of-sync” 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.41 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.42 What is an Operating System,… Really? Operating System Definition (Cont.) • Most Likely: • No universally accepted definition – Memory Management • “Everything a vendor ships when you order an – I/O Management operating system” is good approximation – CPU Scheduling – But varies wildly – Communications? (Does Email belong in OS?) • “The one program running at all times on the – Multitasking/multiprogramming? computer” is the kernel. • What about? – Everything else is either a system program (ships – File System? with the operating system) or an application – Multimedia Support? program – User Interface? – Internet Browser?  • Is this only interesting to Academics?? 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.43 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.44 

12 . Example: Protecting Processes from Each Other Address Translation • Address Space • Problem: Run multiple applications in such a way that they are protected from one another – A group of memory addresses usable by something – Each program (process) and kernel has potentially • Goal: different address spaces. – Keep User Programs from Crashing OS • Address Translation: – Keep User Programs from Crashing each other – Translate from Virtual Addresses (emitted by CPU) – [Keep Parts of OS from crashing other parts?] into Physical Addresses (of memory) • (Some of the required) Mechanisms: – Mapping often performed in Hardware by Memory – Address Translation Management Unit (MMU) – Dual Mode Operation Virtual Physical Addresses Addresses • Simple Policy: CPU MMU – Programs are not allowed to read/write memory of other Programs or of Operating System 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.45 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.46 Example of Address Translation Address Translation Details Data 2 • For now, assume translation happens with table Code Code Stack 1 (called a Page Table): Data Data Heap Heap 1 10 Heap Virtual V page no. offset Address Stack Code 1 Stack Stack 2 Page Table Prog 1 Prog 2 Data 1 Virtual Virtual index V Access Rights PA Address Heap 2 Address into Space 1 Space 2 page Code 2 table table located in physical P page no. offset Physical OS code memory 10 Address OS data • Translation helps protection: Translation Map 1 Translation Map 2 – Control translations, control access OS heap & Stacks – Should Users be able to change Page Table??? Physical Address Space 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.47 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.48 

13 . Dual Mode Operation UNIX System Structure • Hardware provides at least two modes: – “Kernel” mode (or “supervisor” or “protected”) – “User” mode: Normal programs executed Applications User Mode • Some instructions/ops prohibited in user mode: Standard Libs – Example: cannot modify page tables in user mode » Attempt to modify  Exception generated • Transitions from user mode to kernel mode: Kernel Mode – System Calls, Interrupts, Other exceptions Hardware 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.49 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.50 Meeting the needs of the Swarm Examples Cloud Services • eWallpaper: Personal – Real-Time scheduling of resources Swarm – Secure loading of code – Privacy maintenance of collected information, communication • Teleconference on nearest wall: – Automatic location of resources » Display, Microphone, Camera, Routers Metropolitan » Resources for transcoding, audio transcription Middleware » Positional tracking – QoS-guaranteed network path to other side • Support for the Swarm: • UnPad: – Discover and Manage resource – Resource location and allocation – Integrate sensors, portable devices, cloud components » Displays, Microphones, Cameras, etc » High-performance streaming of data from the network – Guarantee responsiveness, real-time behavior, throughput – ID-Based personalization – Self-adapt to adjust for failure and provide performance » RFID, Cellphone connection, other methods for root keys predictability » Targeted advertisement, personalized focus on – Secure, high-performance, durable, available data – Deep archival storage  permanent digital history of activity 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.51 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.52 

14 . New Structures for Multicore chips? Tessellation: The Exploded OS OS Systems Principles • Normal Components split • OS as illusionist: into pieces Firewall Virus – Device drivers (Security/Reliability) – Make hardware limitations go away Large Compute-Bound Intrusion – Network Services – Provide illusion of dedicated machine with infinite (Performance) memory and infinite processors Application Monitor » TCP/IP stack And » Firewall • OS as government: » Virus Checking Adapt » Intrusion Detection – Protect users from each other Real-Time Video & – Persistent Storage – Allocate resources efficiently and fairly Window (Performance, Application Drivers Security, Reliability) • OS as complex system: – Monitoring services » Performance counters – Constant tension between simplicity and Identity Persistent HCI/ Device » Introspection functionality or performance Storage & Voice Drivers – Identity/Environment • OS as history teacher File System Rec services (Security) » Biometric, GPS, Possession Tracking – Learn from past • Applications Given – Adapt as hardware tradeoffs change Larger Partitions – Freedom to use resources arbitrarily 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.53 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.54 Why Study Operating Systems? “In conclusion…” • Learn how to build complex systems: • Operating systems provide a virtual machine – How can you manage complexity for future projects? abstraction to handle diverse hardware • Engineering issues: • Operating systems coordinate resources and – Why is the web so slow sometimes? Can you fix it? protect users from each other – What features should be in the next mars Rover? • Operating systems simplify application development by providing standard services – How do large distributed systems work? (Kazaa, etc) • Operating systems can provide an array of fault • Buying and using a personal computer: containment, fault tolerance, and fault recovery – Why different PCs with same CPU behave differently – How to choose a processor (Opteron, Itanium, Celeron, • CS194-24 combines things from many other areas Pentium, Hexium)? [ Ok, made last one up ] of computer science – – Should you get Windows XP, 2000, Linux, Mac OS …? – Languages, data structures, hardware, and – Why does Microsoft have such a bad name? algorithms • Business issues: • CS194-24 also introduces you to real code development: – Should your division buy thin-clients vs PC? – Test-Driven Development, GDB, Source Control, • Security, viruses, and worms Real implementation in Linux code base! – What exposure do you have to worry about? 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.55 1/22/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 1.56