1
play

1 The OS and User Applications The OS and User Applications - PDF document

Sep 27, 2022 •230 likes •274 views

Operating Systems: The Big Picture Operating Systems: The Big Picture The operating system (OS) is the interface between user applications and the hardware. CPS 210: Operating Systems CPS 210: Operating Systems User Applications virtual

  1. Operating Systems: The Big Picture Operating Systems: The Big Picture The operating system (OS) is the interface between user applications and the hardware. CPS 210: Operating Systems CPS 210: Operating Systems User Applications virtual machine interface Operating System physical machine interface Architecture An OS implements a sort of virtual machine that is easier to program than the raw hardware. [McKinley] Operating Systems: The Classical View Operating Systems: The Classical View Key Concepts Key Concepts kernel The software component that controls the hardware directly, and implements the core privileged OS functions. data data Modern hardware has features that allow the OS kernel to protect itself processes from untrusted user code. thread An executing stream of instructions and its CPU register context. virtual address space threads An execution context for thread(s) that provides an independent name space for addressing some or all of physical memory. process The Kernel An execution of a program, consisting of a virtual address space, one or more threads, and some OS kernel state. Operating Systems: The Classical View Operating Systems: The Classical View Classical View: The Questions Classical View: The Questions The basic issues/questions in this course are how to : The kernel sets processes • allocate memory and storage to multiple programs? up process in private data data • share the CPU among concurrently executing programs? execution virtual contexts to address • suspend and resume programs? “virtualize” the spaces machine. • share data safely among concurrent activities? • protect one executing program’s storage from another? ...and upcalls (e.g., system call traps signals) • protect the code that implements the protection, and Threads or mediates access to resources? shared kernel processes code and data • prevent rogue programs from taking over the machine? enter the in shared kernel for • allow programs to interact safely? address space services. CPU and devices force entry to the kernel to handle exceptional events. 1

  2. The OS and User Applications The OS and User Applications Overview of OS Services Overview of OS Services The OS defines a framework for users and their programs to Storage : primitives for files, virtual memory , etc. coexist, cooperate, and work together safely, supporting: Control devices and provide for the “care and feeding” of the memory system hardware and peripherals. • concurrent execution/interaction of multiple user programs Protection and security • shared implementations of commonly needed facilities Set boundaries that limit damage from faults and errors. “The system is all the code you didn’t write.” Establish user identities, priorities, and accountability. • mechanisms to share and combine software components Mediate/control access for logical and physical resources . Extensibility : add new components on-the-fly as they are developed. • policies for safe and fair sharing of resources Execution : primitives to create/execute programs physical resources (e.g., CPU time and storage space) support an environment for developing and running applications logical resources (e.g., data files, programs, mailboxes) Communication : “glue” for programs to interact The OS and the Hardware The OS and the Hardware Architectural Foundations of OS Kernels Architectural Foundations of OS Kernels • One or more privileged execution modes (e.g., kernel mode ) The OS is the “permanent” software with the power to: protected device control registers • control/abstract/mediate access to the hardware privileged instructions to control basic machine functions interrupts CPUs and memory • System call trap instruction and protected fault handling Processor User processes safely enter the kernel to access shared OS services. I/O devices Cache • Virtual memory mapping • so user code can be: Memory Bus I/O Bridge OS controls virtual-physical translations for each address space. simpler I/O Bus Main • Device interrupts to notify the kernel of I/O completion etc. device-independent Memory Includes timer hardware and clock interrupts to periodically return portable Disk Graphics Network Controller Controller Interface control to the kernel as user code executes. even “transportable” • Atomic instructions for coordination on multiprocessors Graphics Disk Disk Network Introduction to Virtual Addressing Introduction to Virtual Addressing CPS 210, Spring 2002 CPS 210, Spring 2002 virtual Part I physical memory memory User processes • The stuff you should already know. The kernel controls (big) (small) address memory the virtual- physical Part II through virtual translations in effect text addresses . for each space. • The stuff you should learn. data data BSS Part III The kernel and the The machine does not machine collude to user stack • The questions we’re trying to answer now through ongoing allow a user process translate virtual args/env research in “systems”. to access memory addresses to kernel unless the kernel physical addresses. “says it’s OK”. Tanenbaum : undergrad OS text. virtual-to-physical Research papers: 10-12 to 20. translations The specific mechanisms for implementing virtual address translation are machine-dependent . 2

  3. CPS 210: Part I CPS 210: Part I What is Nachos? (Part 1) What is Nachos? (Part 1) Concurrency and synchronization MIPS User Applications Threads and processes, race conditions, mutexes, semaphores, coordination, condition variables, starvation and deadlock User Applications Nachos “OS” • Everyone has to know this stuff. • A few lectures, problem set + exam 1/29 Operating System Solaris OS Classical operating systems Processes and the kernel, system calls, kernel services, file I/ O, Architecture Architecture virtual memory. • A few more lectures. Nachos is designed to look, feel, and crash like a “real” OS. • New this semester: the infamous Nachos labs: 2/5 and 2/19. Both the Nachos “OS” and test programs run together as an ordinary process on an ordinary Unix system (Solaris). What is Nachos? (Part 2) What is Nachos? (Part 2) Nachos: A Peek Under the Hood Nachos: A Peek Under the Hood shell cp User Applications MIPS User Applications user space data data MIPS instructions executed by SPIM Operating System Nachos “OS” ExceptionHandler() Nachos Architecture Solaris OS SPIM kernel MIPS emulator Machine::Run() Architecture fetch/execute SaveState/RestoreState examine/deposit examine/deposit Nachos runs real user programs on a simulated machine. Rn process MIPS simulator in Nachos executes real user programs. page Machine SP table page object PC The real OS is treated as part of the underlying hardware. tables memory registers Overview of Overview of the the Nachos Labs Nachos Labs Secrets of the Nachos Labs Secrets of the Nachos Labs Lab 1 It’s the thought that counts. • Synchronization primitives “from scratch”. • Think before you design it. • Think before you code it. Uniprocessor kernel-mode mutexes and condition variables. • Think before you run it. • Kernel process management system calls. • Think before you debug it. Like Unix fork/exec/exit/wait with simple virtual memory. The time needed to conceive and write the code is moderate, but debugging time is potentially unbounded. Lab 2 • Interprocessor communication using pipes and I/O descriptors. • Simple command shell and user programs. • Paged virtual memory with page cache management. 3

Recommend

More recommend