CPS 210: Operating SystemsOperating Systems: The Big PictureOperating Systems: The Classical ViewKey ConceptsSlide 5Classical View: The QuestionsThe OS and User ApplicationsOverview of OS ServicesThe OS and the HardwareArchitectural Foundations of OS KernelsIntroduction to Virtual AddressingCPS 210, Spring 2002CPS 210: Part IWhat is Nachos? (Part 1)What is Nachos? (Part 2)Nachos: A Peek Under the HoodOverview of the Nachos LabsSecrets of the Nachos LabsCPS 210: Part IIEffect of Hardware on SoftwareHistory LessonThe World TodayCPS 210: Part IIIE-Track, G-Track, and GradingCPS 210: Operating SystemsCPS 210: Operating SystemsThe operating system (OS) is the interface between user applications and the hardware.An OS implements a sort of virtual machine that is easier to program than the raw hardware.Operating Systems: The Big PictureOperating Systems: The Big Picture[McKinley]physical machine interfaceUser ApplicationsOperating SystemArchitecturevirtual machine interfaceOperating Systems: The Classical ViewOperating Systems: The Classical Viewdata dataprocessesthreadsThe KernelKey ConceptsKey ConceptskernelThe software component that controls the hardware directly, and implements the core privileged OS functions.Modern hardware has features that allow the OS kernel to protect itself from untrusted user code. threadAn executing stream of instructions and its CPU register context. virtual address spaceAn execution context for thread(s) that provides an independent name space for addressing some or all of physical memory. processAn execution of a program, consisting of a virtual address space, one or more threads, and some OS kernel state.Operating Systems: The Classical ViewOperating Systems: The Classical Viewdata dataprocesses in private virtual address spacessystem call traps...and upcalls (e.g., signals)shared kernel code and data in shared address spaceThreads or processes enter the kernel for services.The kernel sets up process execution contexts to “virtualize” the machine.CPU and devices force entry to the kernel to handle exceptional events.Classical View: The QuestionsClassical View: The QuestionsThe basic issues/questions in this course are how to:•allocate memory and storage to multiple programs?•share the CPU among concurrently executing programs?•suspend and resume programs?•share data safely among concurrent activities?•protect one executing program’s storage from another?•protect the code that implements the protection, and mediates access to resources?•prevent rogue programs from taking over the machine?•allow programs to interact safely?The OS and User ApplicationsThe OS and User ApplicationsThe OS defines a framework for users and their programs to coexist, cooperate, and work together safely, supporting:•concurrent execution/interaction of multiple user programs•shared implementations of commonly needed facilities“The system is all the code you didn’t write.”•mechanisms to share and combine software componentsExtensibility: add new components on-the-fly as they are developed.•policies for safe and fair sharing of resourcesphysical resources (e.g., CPU time and storage space)logical resources (e.g., data files, programs, mailboxes)Overview of OS ServicesOverview of OS ServicesStor age: primitives for files, virtual memory, etc.Control devices and provide for the “care and feeding” of the memory system hardware and peripherals.Protection and securitySet boundaries that limit damage from faults and errors.Establish user identities, priorities, and accountability.Mediate/control access for logical and physical resources.Execution: primitives to create/execute programssupport an environment for developing and running applications Communicat ion: “glue” for programs to interactThe OS and the HardwareThe OS and the HardwareThe OS is the “permanent” software with the power to:•control/abstract/mediate access to the hardwareCPUs and memoryI/O devices•so user code can be:simplerdevice-independentportableeven “transportable”I/O BusMemory BusProcessorCacheMainMemoryDiskControllerDisk DiskGraphicsControllerNetworkInterfaceGraphicsNetworkinterruptsI/O BridgeArchitectural Foundations of OS KernelsArchitectural Foundations of OS Kernels•One or more privileged execution modes (e.g., kernel mode)protected device control registersprivileged instructions to control basic machine functions•System call trap instruction and protected fault handlingUser processes safely enter the kernel to access shared OS services.•Virtual memory mappingOS controls virtual-physical translations for each address space.•Device interrupts to notify the kernel of I/O completion etc.Includes timer hardware and clock interrupts to periodically return control to the kernel as user code executes.•Atomic instructions for coordination on multiprocessorsIntroduction to Virtual AddressingIntroduction to Virtual AddressingtextdataBSSuser stackargs/envkerneldatavirtualmemory(big)physicalmem or y(small)virtual-to-physical translationsUser processes address memory through virtual addresses.The kernel and the machine collude to translate virtual addresses to physical addresses.The kernel controls the virtual-physical translations in effect for each space.The machine does not allow a user process to access memory unless the kernel “says it’s OK”.The specific mechanisms for implementing virtual address translation are machine-dependent.CPS 210, Spring 2002CPS 210, Spring 2002Part I•The stuff you should already know.Part II•The stuff you should learn.Part III•The questions we’re trying to answer now through ongoing research in “systems”.Tanenbaum: undergrad OS text.Research papers: 10-12 to 20.CPS 210: Part ICPS 210: Part IConcurrency and synchronizationThreads and processes, race conditions, mutexes, semaphores, coordination, condition variables, starvation and deadlock•Everyone has to know this stuff.•A few lectures, problem set + exam 1/29Classical operating systemsProcesses and the kernel, system calls, kernel services, file I/O, virtual memory.•A few more lectures.•New this semester: the infamous Nachos labs: 2/5 and 2/19.Nachos is designed to look, feel, and crash like a “real” OS.Both the Nachos “OS” and test programs run together as an ordinary process on an ordinary Unix system (Solaris).What is Nachos? (Part 1)What is Nachos? (Part 1)User ApplicationsOperating