1 / 42

1. Introduction

1. Introduction 1.1 The Role of Operating Systems - Bridge the “Semantic Gap” between Hardware and Application - Three Views of Operating Systems 1.2 Organization of Operating Systems - Structural Organization - The Hardware Interface

Antony
Download Presentation

1. Introduction

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. 1. Introduction 1.1 The Role of Operating Systems - Bridge the “Semantic Gap” between Hardware and Application - Three Views of Operating Systems 1.2 Organization of Operating Systems - Structural Organization - The Hardware Interface - The Programming Interface - The User Interface - Runtime Organization 1.3 Operating System Evolution & Concepts

  2. Single CPU System Figure 1-1

  3. Bridging the Semantic Gap • Hardware capabilities are very low level • Arithmetic and logical operators • Comparison of two bit-strings • Branching, reading, and writing bytes • User needs to think in terms of problem to be solved • High-level data structures and corresponding operations • Simple, uniform interfaces to subsystems, • Treat programs and data files as single entities • Use software to bridge this gap • Language processors (e.g., assemblers, compilers, interpreters). • Editors and text processors, linkers and loaders. • Application programs, utility and service programs. • Operating Systems

  4. The role of OSs • Bridge Hardware/Application Gap • Machine instruction vs high level operation • compiler bridges gap • Linear memory vs data structures • compiler bridges gap • Limited CPU & memory vs more needed • OS bridges gap • Secondary memory devices vs files • OS bridges gap • I/O devices vs high level I/O commands • OS bridges gap

  5. Multiprocessor Systems Figure1-2a Figure 1-2b

  6. Multicomputer System Figure 1-2c

  7. PC Hardware Organization Figure 1-7

  8. Three views of OSs • OS is an extended machine • Principle of abstraction hides complexity • OS provides high level operations using lower level operations • OS is a virtual machine • Principle of virtualization supports sharing • OS provides virtual CPU, memory, devices • OS is a resource manager • Balance overall performance with individual needs (response time, deadlines)

  9. Structural Organization of OSs • Monolithic vs Layered Figure 1-8

  10. Organization of OSs • Hardware Interface • Applications and OS compiled into machine instructions • Interrupts and Traps allow OS to seize control • process management (time-sharing) • device management (I/O completion)

  11. Principles of Interupts and Traps Figure 1-9

  12. Organization of OSs • Hardware interface (continued) • Modes of CPU execution • Privileged/Nonprivileged • SVC (supervisor call) causes trap • Control transferred to OS in privileged mode • OS exits privileged mode when returning to user

  13. Organization of OSs • Programming Interface • Invoking system services • Library call (nonprivileged) • Kernel call (privileged) Figure 1-8

  14. Invoking System Services Figure 1-10

  15. Organization of OSs • User interface (cf. Fig. 1-8) • Text-based shell (e.g. Unix) • command interpreter • shell scripts • Graphics-based GUI (e.g. Mac, MS Windows) • Windows • Icons • Menus • Pointer

  16. Organization of OSs • Runtime organization • Service is a Subroutine • Service is an Autonomous Process (“client-server”) Figure 1-12

  17. OS Evolution and Concepts • Early systems • Bootstrapping • Batch OSs • I/O processors • Interrupts • Relocatable code • Multiprogramming

  18. Multiprogramming • Basic problem: • Some programs are compute-bound, some I/O-bound • Even “balanced” programs are balance only over time • No one program can make full use of the system • Solution: Multiprogramming • Have more than one active (running) program in memory at any one time • Multiprogramming requires • Bridging the semantic gap • Sharing resources among different programs • Hiding from each program the fact of this sharing

  19. OS Evolution and Concepts • Multiprogramming Systems • Overlap CPU and I/O • Protection • Synchronization and Communication • Dynamic Memory Management (swapping and paging) • Interactive OSs • Guaranteed response time • Time-sharing (quantum)

  20. Batch Processing • Uses multiprogramming Job (file of OS commands) prepared offline • Batch of jobs given to OS at one time • OS processes jobs one-after-the-other • No human-computer interaction • OS optimizes resource utilization • Batch processing (as an option) still used today

  21. Shell Command Line Interpreter Interactive User Application & System Software Shell Program OS System Call Interface OS

  22. The Shell Strategy % grep first f3 fork a process read keyboard Shell Process Process to execute command f3 read file

  23. Initializing a UNIX Machine Serial Port A login Serial Port B login Serial Port C login Serial Port Z login getty /etc/passwd

  24. A Shell Script Batch File gcc -g -c menu.c gcc -g -o driver driver.c menu.o driver < test_data > test_out lpr –Ppr0 test_out tar cvf driver_test.tar menu.c driver.c test_data test_out uuencode driver_test.tar driver_test.tar >driver_test.encode

  25. UNIX Files • UNIX and NT try to make every resource (except CPU and RAM) look like a file • Then can use a common interface: open Specifies file name to be used close Release file descriptor read Input a block of information write Output a block of information lseek Position file for read/write ioctl Device-specific operations

  26. UNIX File Example #include <stdio.h> #include <fcntl.h> int main() { int inFile, outFile; char *inFileName = “in_test”; char *outFileName = “out_test”; int len; char c; inFile = open(inFileName, O_RDONLY); outFile = open(outFileName, O_WRONLY); /* Loop through the input file */ while ((len = read(inFile, &c, 1)) > 0) write(outFile, &c, 1); /* Close files and quite */ close(inFile); close(outFile); }

  27. OS Evolution and Concepts • PC and workstation OSs • GUI • Real-time OSs • Deadlines (scheduling) • Distributed OSs • Loosely coupled/tightly coupled • Consistent timeline (logical clocks, time stamps)

  28. Examples of Modern OS • UNIX variants (e.g. Linux) -- have evolved since 1970 • Windows NT/2K -- has evolved since 1989 • VxWorks for real-time • Research OSes – still evolving … • Small computer OSes – still evolving

  29. Requirements from a Modern OS 1. Micro-kernel structure Scheduling Networking Device Drivers Memory Management Scheduling IP Communication Everything else is built as utilities

  30. Requirements (cont.) 2. Multi-threading - A process consists of threads - Threads run concurrently - A thread is schedulable and interruptable - User and kernel threads 3. Symmetric Multiprocessing - More than one processors -> speed and fault tol. - Incremental growth is possible

  31. Requirements (cont.) 4. Distributed Operating System - Running on many processors (clusters) - Vision of one OS - Fault Tolerance increased - Performance, resource utilization - Still a research issue – not many around - Distributed and Mobile and Real-time ??? that seems to be the future of OS !

  32. Processor Modes • Mode bit: Supervisor or User mode • Supervisor mode • Can execute all machine instructions • Can reference all memory locations • User mode • Can only execute a subset of instructions • Can only reference a subset of memory locations

  33. Kernels • The part of the OS critical to correct operation (trusted software) • Executes in supervisor mode • The trap instruction is used to switch from user to supervisor mode, entering the OS

  34. Supervisor and User Memory User Space User Process Supervisor Process Supervisor Space

  35. send(…, A, …); receive(…, B, …); send/receive receive(…A, …); … send(…, B, …); Procedure Call and Message Passing Operating Systems call(…); trap return;

  36. System Call Using the trap Instruction … fork(); … Trap Table Kernel fork() { … trap N_SYS_FORK() … } sys_fork() sys_fork() { /* system function */ … return; }

  37. A Thread Performing a System Call User Space Kernel Space Thread fork(); sys_fork() { }

  38. File Manager Memory Manager Device Manager Basic Operating System Organization Process, Thread & Resource Manager Processor(s) Main Memory Devices

  39. The UNIX Architecture Interactive User Libraries Commands Application Programs … OS System Call Interface Trap Table Device Driver • Monolithic Kernel Module • Process Management • Memory Management • File Management • Device Mgmt Infrastructure Device Driver … Driver Interface Device Driver

  40. Microkernel Organization Process Process Libraries Process User Supervisor Server Server Server Device Drivers Microkernel Processor(s) Main Memory Devices

  41. Windows NT Organization Process Process T T Process T T T T Libraries T T T Process Management Memory Management File Management Device Mgmt Infrastructure Subsystem Subsystem Subsystem User Supervisor I/O Subsystem NT Executive NT Kernel Hardware Abstraction Layer Processor(s) Main Memory Devices

  42. Abstraction • E.W.Dijkstra, “The Humble Programmer” (1972): “The purpose of abstraction is not to be vague, but to create a new semantic levelin which one can be absolutely precise.” • “abstraction” is created by distinguishing • Essential characteristics fromUnimportant details • Build levels (layers) of abstractions: • What is unimportant detail at one levelis an essential characteristic at a lower one.

More Related