Composition and Evolution of Operating Systems Introduction to Operating Systems: Module 2

Outline u I/O review  Direct Memory Access u Operating System as a Computer Interface u Operating System as a Resource Manager u Evolution of Operating Systems u Layout of an Operating System u Operating System Components u Case studies  Unix  Windows

Methods of I/O u Polling  Calling program repeatedly asks: “Are you done yet?” u Interrupt driven  Device alerts CPU: “I’m done!” u Direct memory access (DMA)  CPU tells DMA: “You handle this.”

Burst DMA u CPU issues DMA request  separate DMA module  DMA part of I/O module u DMA module transfers a block of data directly to memory  Data is moved one word at a time  The CPU executes no-ops while data is transferred u An interrupt is sent when the task is complete u The CPU is only involved at the start and end of the transfer CPUDMA Block request. Move 1 word. Move 1 word. Raise interrupt. IH calls ISR. ISR resumes program. Continue.

DMA with cycle stealing u CPU makes DMA request u With each subsequent instruction  The DMA module uses memory cycles which the instruction does not use. u When data transfer is complete DMA module raises an interrupt CPUDMA Block request. Move 1 word. Use bus. Move 1 word. Use bus. Raise interrupt. IH calls ISR. ISR resumes program. Continue.

OS as a Computer Interface u Applications: The only visible component to the user u Libraries provide the programming interface to services provided by the OS. u The Operating System hides the details of the hardware. It provides services that allow applications to:  create and run other programs  access I/O devices and files  communicate with other programs  request resources such as memory  controlled access to shared resources such as memory, files, I/O devices Libraries Application Operating System Hardware User

Libraries Application Operating System Hardware User Libraries u OS services provided through a set of system calls, which are protected procedures and are accessed through a TRAP instruction u TRAP instructions are architecture dependent. A system call requires:  Placing parameters in specific places, such as the stack or CPU registers  Issuing a trap instruction u Libraries hide the details of the TRAP instruction  They make system calls look like ordinary function calls System call using TRAP instruction

OS as a Resource Manager u Users usually run several applications concurrently u The OS is in charge of assigning, protecting and controlling system resources among concurrent applications u Different resources are shared in different ways  CPU, disk and network resources are shared by having applications take short turns at using the resources  Memory is shared by splitting the memory space among multiple applications  Printers can only be used by a single application until it has finished using it

Evolution of an Operating System u Must adapt to hardware upgrades and new types of hardware. Examples:  Character vs. graphic terminals  Introduction of paging hardware u Must offer new services  distributed system support  multimedia support u The need to change the OS on a regular basis imposes requirements on its design  modular construction with clean interfaces  object oriented methodology

Simple Batch Systems u The first operating systems (mid-50s) u The user submits a job (written on card or tape) to a computer operator u The computer operator places a batch of several jobs on an input device u A special program, the monitor, manages the execution of each program in the batch  always in main memory and available for execution u Monitor utilities are loaded when needed

Multiprogrammed Batch Systems u I/O operations are exceedingly slow (compared to instruction execution) u A program containing even a very small number of I/O ops, will spend most of its time waiting for them u Hence: poor CPU usage when only one program is present in memory

Multiprogrammed Batch Systems u If memory can hold several programs, then CPU can switch to another one whenever a program is awaiting for an I/O to complete u This is multiprogramming

Time Sharing Systems u Batch multiprogramming does not support interaction with users u TSS extends multiprogramming to handle multiple interactive jobs u Processor’s time is shared among multiple users u Multiple users simultaneously access the system The file system must be protected  multiple users  multiple processes (tasks) per user

Time Sharing Systems (TSS) u Because of slow human reaction time, a typical user needs 2 seconds (or less) of processing time per minute u Hence approximately 30 users should be able to share the same system without noticeable delay in the computer reaction time

Layout of an Operating System u The OS (or part of it) runs within the currently executing process u The part of the OS called the kernel is mapped into each process' memory u There is only one instance of the kernel in memory Application 1 OS App1 code Shared Libraries App1 Stack App1 data Not used Application 2 OS App2 code Shared Libraries App2 Stack App2 data Not used OS App1 data App2 Stack App1 code Not used App1 Stack Shared Libraries App2 code App2 data Not used Main Memory

Virtual Memory u Virtual memory a main topic in OS and will be covered in detail later in the course. u Each process has its own view of the memory called its address space Application 1 OS App1 code Shared Libraries App1 Stack App1 data Not used Application 2 OS App2 code Shared Libraries App2 Stack App2 data Not used OS App1 data App2 Stack App1 code Not used App1 Stack Shared Libraries App2 code App2 data Not used Main Memory

Virtual Memory u The components of each application’s address space are mapped somewhere in physical memory u Each address in a program’s address space is mapped into a physical address, they need not be the same. u Each program thinks it has the entire memory to itself Application 1 OS App1 code Shared Libraries App1 Stack App1 data Not used Application 2 OS App2 code Shared Libraries App2 Stack App2 data Not used OS App1 data App2 Stack App1 code Not used App1 Stack Shared Libraries App2 code App2 data Not used Main Memory

Operating System Components u Process management u Memory management u Secondary-storage management u I/O system management u File management u Protection/Security system u Networking u User interface

Process Management u A process is a program in execution. It needs certain resources, including CPU time, memory, files, and I/O devices, to accomplish its tasks. u The operating system is responsible for:  process creation and deletion  process suspension and resumption  process synchronization  process communication

Main-Memory Management u A single memory space is allocated to (possibly) many processes u The management of memory should be transparent to the processes u The operating system is responsible for:  Allocating, de-allocating memory  Decide which processes to load when memory space becomes available  Allocate and de-allocate memory space as needed

Secondary-Storage Management u Disk devices, used to store data between sessions, have their capacity divided into blocks  Each file on the disk is made of 1 or more blocks  The used portion of the disk is also divided into blocks u Free space management u Storage allocation

File Management u File creation and deletion u Directory creation and deletion u Support of primitives for manipulating files and directories u Mapping files onto secondary storage u File backup on nonvolatile storage media

Protection System u Protection refers to a mechanism for controlling access by programs, processes, or users to both system and user resources. u The protection mechanism must:  distinguish between authorized and unauthorized usage by recognized system entities  This is not the same as security, which is the policy for access to system resources  specify the controls to be imposed  provide a means of enforcement

How protection breaks down u User process directly accessing another user process' storage u User process taking over part of the OS and using this to overwrite other processes or even modify the OS itself  MS-DOS allowed this u Prevent the OS up from accessing the CPU with an infinite loop

Basic protection mechanisms: hardware u Two CPU modes  user mode (your code runs here)  supervisor mode (the kernel runs here) u Privileged instructions  only executable is supervisor mode  trap to OS generated if execution attempted in user mode u Memory protection  addresses are transformed by memory mapping  It is impossible to access another processes memory space without OS intervention

Basic protection mechanisms: software u Authentication  From passwords to retina scans, the system should provide a method of identifying users u File (or other resource) attributes  Provide a means to specify which users have access, and what type of access is granted u Encryption  Used to protect data from unauthorized access during transit through non-secured domains