Transcript L02_OperatingSystemEvolution

Composition and Evolution of
Operating Systems
Introduction to Operating Systems: Module 2
Outline
 I/O
review
 Direct
Memory Access
 Operating
System as a Computer Interface
 Operating System as a Resource Manager
 Evolution of Operating Systems
 Layout of an Operating System
 Operating System Components
 Case studies
 Unix
 Windows
Methods of I/O
Polling
Calling
program repeatedly asks:
“Are you done yet?”
Interrupt
Device
Direct
CPU
driven
alerts CPU: “I’m done!”
memory access (DMA)
tells DMA: “You handle this.”
Burst DMA

CPU issues DMA request



DMA module transfers a block
of data directly to memory




separate DMA module
DMA part of I/O module
Data is moved one word at a time
The CPU executes no-ops while
data is transferred
An interrupt is sent when the
task is complete
The CPU is only involved at the
start and end of the transfer
CPU
DMA
Block request.
Move 1 word.
Move 1 word.
<idle>
Move 1 word.
Raise interrupt.
IH calls ISR.
ISR resumes program.
Continue.
DMA with cycle stealing
 CPU
makes DMA request
 With each subsequent
instruction

The DMA module uses
memory cycles which the
instruction does not use.
data transfer is
complete DMA module
raises an interrupt
CPU
DMA
Block request.
Move 1 word.
Move 1 word.
Use bus.
Move 1 word.
 When
Use bus.
Raise interrupt.
IH calls ISR.
ISR resumes program.
Continue.
OS as a Computer Interface
 Applications: The
only visible
component to the user
 Libraries provide the programming
interface to services provided by the OS.
 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

User
Application
Libraries
Operating System
Hardware
Libraries


OS services provided through a set of
system calls, which are protected
procedures and are accessed through a
TRAP instruction
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
Libraries hide the details of the TRAP
instruction

They make system calls look like ordinary
function calls
User
System call
using TRAP
instruction
Application
Libraries
Operating System
Hardware
OS as a Resource Manager
 Users
usually run several applications concurrently
 The OS is in charge of assigning, protecting and
controlling system resources among concurrent
applications
 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
 Must
adapt to hardware upgrades and new types of
hardware. Examples:
Character vs. graphic terminals
 Introduction of paging hardware

 Must
offer new services
distributed system support
 multimedia support

 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
 The
first operating systems (mid-50s)
 The user submits a job (written on card or tape) to
a computer operator
 The computer operator places a batch of several
jobs on an input device
 A special program, the monitor, manages the
execution of each program in the batch
 always
 Monitor
in main memory and available for execution
utilities are loaded when needed
Multiprogrammed Batch Systems
 I/O
operations are exceedingly slow (compared to
instruction execution)
 A program containing even a very small number of I/O
ops, will spend most of its time waiting for them
 Hence: poor CPU usage when only one program is present
in memory
Multiprogrammed Batch Systems
 If
memory can hold several programs, then CPU can
switch to another one whenever a program is awaiting for
an I/O to complete
 This is multiprogramming
Time Sharing Systems
 Batch
multiprogramming does not support
interaction with users
 TSS extends multiprogramming to handle
multiple interactive jobs
 Processor’s time is shared among multiple users
 Multiple users simultaneously access the system
The file system must be protected
 multiple
users
 multiple processes (tasks) per user
Time Sharing Systems (TSS)
 Because
of slow human reaction time, a typical
user needs 2 seconds (or less) of processing time
per minute
 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
Main Memory
OS
Shared Libraries
App1 data
App1 code
App2 Stack
App1 data
Not used
Not used
App1 code
App1 Stack
Not used
App1 Stack
OS
Application 2
OS (or part of it) runs
within the currently
executing process
 The part of the OS called
the kernel is mapped into
each process' memory
 There is only one instance
of the kernel in memory
Application 1
 The
OS
Shared Libraries
Shared Libraries
Not used
App2 code
App2 data
App2 data
Not used
Not used
App2 code
App2 Stack
Not used
Virtual Memory
Main Memory
OS
Shared Libraries
App1 data
App1 code
App2 Stack
App1 data
Not used
Not used
App1 code
App1 Stack
Not used
App1 Stack
OS
Application 2
memory a
main topic in OS and
will be covered in
detail later in the
course.
 Each process has its
own view of the
memory called its
address space
Application 1
 Virtual
OS
Shared Libraries
Shared Libraries
Not used
App2 code
App2 data
App2 data
Not used
Not used
App2 code
App2 Stack
Not used
Virtual Memory
Main Memory
OS
Shared Libraries
App1 data
App1 code
App2 Stack
App1 data
Not used
Not used
App1 code
App1 Stack
Not used
App1 Stack
OS
Application 2
components of each
application’s address
space are mapped
somewhere in physical
memory
 Each address in a
program’s address space
is mapped into a physical
address, they need not be
the same.
 Each program thinks it
has the entire memory to
itself
Application 1
 The
OS
Shared Libraries
Shared Libraries
Not used
App2 code
App2 data
App2 data
Not used
Not used
App2 code
App2 Stack
Not used
Operating System Components
 Process
management
 Memory management
 Secondary-storage management
 I/O system management
 File management
 Protection/Security system
 Networking
 User interface
Process Management
 A process
is a program in execution. It needs
certain resources, including CPU time, memory,
files, and I/O devices, to accomplish its tasks.
 The operating system is responsible for:
 process
creation and deletion
 process suspension and resumption
 process synchronization
 process communication
Main-Memory Management
 A single
memory space is allocated to (possibly)
many processes
 The management of memory should be transparent
to the processes
 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
 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
 Free
space management
 Storage allocation
File Management
 File
creation and deletion
 Directory creation and deletion
 Support of primitives for manipulating files and
directories
 Mapping files onto secondary storage
 File backup on nonvolatile storage media
Protection System
 Protection
refers to a mechanism for controlling
access by programs, processes, or users to both
system and user resources.
 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
 User
process directly accessing another user
process' storage
 User process taking over part of the OS and using
this to overwrite other processes or even modify the
OS itself
 MS-DOS
 Prevent
allowed this
the OS up from accessing the CPU with an
infinite loop
Basic protection mechanisms: hardware
 Two
CPU modes
user mode (your code runs here)
 supervisor mode (the kernel runs here)

 Privileged
instructions
only executable is supervisor mode
 trap to OS generated if execution attempted in user mode

 Memory
protection
addresses are transformed by memory mapping
 It is impossible to access another processes memory space
without OS intervention

Basic protection mechanisms: software
 Authentication
 From
passwords to retina scans, the system should
provide a method of identifying users
 File
(or other resource) attributes
 Provide
a means to specify which users have access, and
what type of access is granted
 Encryption
 Used
to protect data from unauthorized access during
transit through non-secured domains