CHAPTER 1

INTRODUCTION TO
OPERATING SYSTEMS
Class outline
◻ Introduction, concepts, review & historical perspective
◻ Processes
Synchronization
Scheduling
Deadlock
◻ Memory management, address translation, and virtual memory
◻ Operating system management of I/O
◻ File systems
◻ Security & protection
Overview: Chapter 1
◻ What is an operating system, anyway?
◻ Operating systems history
◻ The zoo of modern operating systems
◻ Review of computer hardware
◻ Operating system concepts
◻ Operating system structure
User interface to the operating system
Anatomy of a system call
What is an operating system?
◻ A program that runs on the “raw” hardware and supports
Resource Abstraction
Resource Sharing
◻ Abstracts and standardizes the interface to the user across
different types of hardware
Virtual machine hides the messy details which must be performed
◻ Manages the hardware resources
Each program gets time with the resource
Each program gets space on the resource
◻ May have potentially conflicting goals:
Use hardware efficiently
Give maximum performance to each user
1.1 General Definition

◻ An OS is a program which acts as an interface

between computer system users and the computer
hardware.
◻ It provides a user-friendly environment in which a
user may easily develop and execute programs.
◻ Otherwise, hardware knowledge would be
mandatory for computer programming.
◻ So, it can be said that an OS hides the complexity
of hardware from uninterested users.
1.1 General Definition

◻ In general, a computer system has some resources

which may be utilized to solve a problem. They are
Memory
Processor(s)
I/O
File System
etc.
1.1 General Definition

Mainboard
1.1 General Definition
1.1 General Definition

mainboard
1.1 General Definition

processor
1.1 General Definition

RAM
1.1 General Definition

⚫ The OS manages these resources and allocates them

to specific programs and users.
⚫ With the management of the OS, a programmer is
rid of difficult hardware considerations.
⚫ An OS provides services for
⚫ Processor Management
⚫ Memory Management
⚫ File Management
⚫ Device Management
⚫ Concurrency Control
1.1 General Definition

◻ Another aspect for the

Application Programs
usage of OS is that; it is
used as a predefined library System Programs
for hardware-software
interaction. Operating System

◻ This is why, system programs Machine Language

apply to the installed OS
since they cannot reach HARDWARE

hardware directly.
1.1 General Definition

◻ Since we have an already written library, namely

the OS, to add two numbers we simply write the
following line to our program:
c=a+b;
1.1 General Definition

⚫ in a system where there is no OS installed, we

should consider some hardware work as:
(Assuming an MC 6800 computer hardware)

LDAA $80 🡪 Loading the number at memory location 80

LDAB $81 🡪 Loading the number at memory location 81
ADDB 🡪 Adding these two numbers
STAA $55 🡪 Storing the sum to memory location 55

⚫ As seen, we considered memory locations and used

our hardware knowledge of the system.
1.1 General Definition
◻ In an OS installed machine, since we have an
intermediate layer, our programs obtain some
advantage of mobility by not dealing with
hardware.
◻ For example, the above program segment would
not work for an 8086 machine, where as the
“c = a + b ;”
syntax will be suitable for both.
1.1 General Definition

◻ With the advantage of easier programming

provided by the OS, the hardware, its machine
language and the OS constitutes a new combination
called as a virtual (extended) machine.
Operating
Machine System
Virtual
Language Machine (Extended)
Machine Language
Hardware Machine
Hardware
1.1 General Definition

◻ In a more simplistic approach, in fact, OS itself is a

program.
◻ But it has a priority which application programs
don’t have.
◻ OS uses the kernel mode of the microprocessor,
whereas other programs use the user mode.
◻ The difference between two is that; all hardware
instructions are valid in kernel mode, where some of
them cannot be used in the user mode.
Operating system timeline
◻ First generation: 1945 – 1955
Vacuum tubes
Plug boards
◻ Second generation: 1955 – 1965
Transistors
Batch systems
◻ Third generation: 1965 – 1980
Integrated circuits
Multiprogramming
◻ Fourth generation: 1980 – present
Large scale integration
Personal computers
◻ Next generation: ???
Systems connected by high-speed networks?
Wide area resource management?
1.2 History of Operating Systems

◻ It all started with computer hardware in about

1940s.

ENIAC 1943
1.2 History of Operating Systems

◻ ENIAC (Electronic Numerical Integrator and

Computer), at the U.S. Army's Aberdeen Proving
Ground in Maryland.
built in the 1940s,
weighed 30 tons,
was eight feet high, three feet deep, and 100 feet long
contained over 18,000 vacuum tubes that were cooled
by 80 air blowers.
1.2 History of Operating Systems

◻ Computers were using vacuum tube technology.

ENIAC’s vacuum tubes

1.2 History of Operating Systems

ENIAC’s backside
1.2 History of Operating Systems

Programs were loaded into memory manually using switches, punched

cards, or paper tapes.

ENIAC : coding by cable connections

1.2 History of Operating Systems

punch card
1.2 History of Operating Systems
1.2 History of Operating Systems

Paper tape
1.2 History of Operating Systems
1.2 History of Operating Systems

Babbage’s analytical engine

(designed in 1840’s by Charles Babbage, but could not be constructed by him.
An earlier and simpler version is constructed in 2002, in London )

http://www.computerhistory.org/babbage/
1.2 History of Operating Systems

◻ Ada Lovalence (at time of Charles Babbage) wrote

code for analytical engine to compute Bernulli
Numbers
First generation: direct input
◻ Run one job at a time
Enter it into the computer (might require rewiring!)
Run it
Record the results
◻ Problem: lots of wasted computer time!
Computer was idle during first and last steps
Computers were very expensive!
◻ Goal: make better use of an expensive commodity:
computer time
 Second generation: batch systems

◻ Bring cards to 1401

◻ Read cards onto input tape
◻ Put input tape on 7094
◻ Perform the computation, writing results to output tape
◻ Put output tape on 1401, which prints output
Structure of a typical 2nd generation job

Data for
$END
program

$RUN
FORTRAN $LOAD
program

$FORTRAN
$JOB, 10,6610802, ETHAN MILLER
Third generation: multiprogramming
◻ Multiple jobs in memory
Protected from one another
Job 3 ◻ Operating system protected
from each job as well
Job 2 ◻ Resources (time, hardware)
Memory split between jobs
partitions Job 1
◻ Still not interactive
User submits job
Operating Computer runs it
system User gets results minutes (hours,
days) later
Spooling
◻ Original batch systems used tape drives
◻ Later batch systems used disks for buffering
Operator read cards onto disk attached to the computer
Computer read jobs from disk
Computer wrote job results to disk
Operator directed that job results be printed from disk
◻ Disks enabled simultaneous peripheral operation on-line
(spooling)
Computer overlapped I/O of one job with execution of
another
Better utilization of the expensive CPU
Still only one job active at any given time
Spooling
◻ Stands for Simultaneous Peripheral Operation
On-Line
◻ Takes advantage of disk technology (new at this
point)
◻ Allows for overlap of IO from one job with the
computation of another job
◻ While executing current job
Read next job from card reader to disk
Print previous job to printer
◻ Disk is relegated to the role of a partitioned buffer
Job pool
◻ Advent of disk allows for random access
(Tape and card are sequential)
◻ Several jobs can be waiting on the disk
◻ The job pool is a data structure that contains info and
points to the jobs on the disk
◻ We can now have job scheduling to determine the
order in which the jobs run so that CPU utilization can
increase.
Multitasking (Time-sharing)
◻ Extension of Multiprogramming
Need for user interactivity
Instead of switching jobs when waiting for IO, a timer causes jobs to
switch
◻ User interacts with computer via CRT and keyboard
Systems have to balance CPU utilization against response time
Better device management
◻ Need for file system to allow user to access data and code
◻ Need to provide user with an “interaction environment”
Virtual Memory
◻ Programs can be larger than memory
Program loaded into memory as needed
Active program and data “swapped” to a disk until
needed
◻ Memory space treated uniformly
 rd
Key Events 3 Generation
◻ 1964-1966 IBM/360 and OS/360
◻ 1964 Dartmouth Time Sharing System
◻ 1965 DEC PDP-8
◻ 1965 MIT – Multics Time sharing System
◻ 1969 – Beginnings of ARPANet
◻ 1969 - Unix
◻ 1971 IBM 4001 – Processor on a chip
◻ 1973 – Ethernet concept Bob Metcalf @ Xerox
Parc
◻ 1974 - Gary Kildall – CP/M OS
◻ 1974 Zilog Z80 Processor
Key Events (cont)
◻ 1974 - Edward Roberts, William
Yates and Jim Bybee
MITS Altair 8800.
■ $375
■ contained 256 bytes of memory
■ no keyboard, no display, and no aux
storage device.
◻ 1976 Steve Jobs and Steve
Wozniak
Apple II
◻ 1977 Commodore PET, Radio
Shack TRS_80
◻ 1979 Unix 3BSD
Fourth Generation : (1980 – 1990)
◻ Personal Computers
◻ Computer dedicated to a single user
◻ IO Devices now consist of keyboards, mice, CGA-VGA
displays, small printers
◻ User convenience and responsiveness
◻ Can adopt lessons from larger operating systems
◻ No need for some of the advanced options at the
personal level
 th
Key Events 4 Generation
◻ 1981 IBM PC (8086)
◻ 1981 Osborne 1
◻ 1981 Vic 20
◻ 1981 Xerox Star Workstation
◻ 1984 Apple macintosh
◻ 1984 SunOS
◻ 1985 C++
◻ 1985 MSWindows
◻ 1986 – 386 Chip
 th
Key Events 4 Generation (cont)
◻ 1987 OS/2
◻ 1988 Next Unix Workstations
◻ 1989 Motif
◻ 1990 Windows 3,
◻ 1990 Berners-Lee Prototype for the web
 Types of modern operating systems
◻ Mainframe operating systems: MVS
◻ Server operating systems: FreeBSD, Solaris

◻ Multiprocessor operating systems: Cellular IRIX

◻ Personal computer operating systems: Windows, Unix

◻ Real-time operating systems: VxWorks

◻ Embedded operating systems

◻ Smart card operating systems

⇒ Some operating systems can fit into more than one

category
Components of a simple PC

Outside
world

Video Hard drive USB Network

controller controller controller controller

CPU Computer internals

(inside the “box”)
Memory
 CPU internals
Execut
Decod e
Fetch unit
e
unit
unit
Decod Execut Execut
Fetch Buff
e e e
unit
unit unit
er unit
Decod
Fetch Execut
e
unit e
unit
unit

Pipelined CPU Superscalar CPU

 Storage pyramid
Capacity Access latency
< 1 KB Registers 1 ns Better

1 MB Cache (SRAM) 2–5 ns

256 MB Main memory (DRAM) 50 ns
40 GB Magnetic disk 5 ms
Better > 1 TB Magnetic tape 50 sec

◻ Goal: really large memory with very low latency

Latencies are smaller at the top of the hierarchy
Capacities are larger at the bottom of the hierarchy
◻ Solution: move data between levels to create illusion of large
memory with low latency
 Disk drive structure
49
head
◻ Data stored on surfaces secto
Up to two surfaces per platter r
One or more platters per disk
◻ Data in concentric tracks platte
r
Tracks broken into sectors trac
■ 256B-1KB per sector k
cylinde
Cylinder: corresponding tracks r
on all surfaces
◻ Data read and written by surface
heads s
Actuator moves heads
Heads move in unison spindl
e actuator
 Memory
Address Address
0x2ffff 0x2ffff
User program User data
0x2d000
and data
0x2b000 0x2bfff Limit2
User data
0x27fff Limit 0x29000 Base2
User program
0x24fff Limit1
0x23000
and data User program
Base 0x23000 Base1
0x1dfff 0x1dfff
Operating Operating
system system
0 0

◻ Single base/limit pair: set for each process

◻ Two base/limit registers: one for program, one for data
 Anatomy of a device request
Instructionn
3 2 Instructionn+1
1: Interrupt
5 Interrupt Disk
CPU
controller controller
1 6 4
Operating
system 3: Return
Interrupt handler
◻ Left: sequence as seen by hardware 2: Process interrupt
Request sent to controller, then to disk
Disk responds, signals disk controller which tells interrupt controller
Interrupt controller notifies CPU
◻ Right: interrupt handling (software point of view)
Operating systems concepts
◻ Many of these should be familiar to Unix users…
◻ Processes (and trees of processes)
◻ Deadlock
◻ File systems & directory trees
◻ Pipes
◻ We’ll cover all of these in more depth later on, but
it’s useful to have some basic definitions now
 Processes
◻ Process: program in execution
A Address space (memory) the
program can use
State (registers, including program
counter & stack pointer)
B C D ◻ OS keeps track of all processes in
a process table
◻ Processes can create other
processes
E F G Process tree tracks these
relationships
A is the root of the tree
A created three child processes: B,
C, and D
C created two child processes: E
and F
D created one child process: G
 Inside a (Unix) process
54

0x7fffffff ◻ Processes have three

Stack segments
Text: program code
Data: program data
■ Statically declared variables
■ Areas allocated by malloc() or
new
Stack
Data
Data ■ Automatic variables
■ Procedure call information
◻ Address space growth
Text
Text: doesn’t grow
0 Data: grows “up”
Stack: grows “down”
Deadlock

Potential deadlock Actual deadlock

 Hierarchical file systems
CS 1550,
cs.pitt.edu
(originaly
modified by
Ethan L. Miller
and Scott A.
Brandt)
Root directory

bin cse

faculty grads

ls ps cp csh
elm sbrandt kag amer4

classes research
stuff stuff
 Interprocess communication
◻ Processes want to exchange information with each other
◻ Many ways to do this, including
Network
Pipe (special file): A writes into pipe, and B reads from it

A B
System calls
◻ Programs want the OS to perform a service
Access a file
Create a process
Others…
◻ Accomplished by system call
Program passes relevant information to OS
OS performs the service if
■ The OS is able to do so
■ The service is permitted for this program at this time
OS checks information passed to make sure it’s OK
■ Don’t want programs reading data into other 1programs’
58 Chapter
 Making a system call
0xffffffff
Library
◻ System call:
(read call) read(fd,buffer,length)
◻ Program pushes arguments,
Return to caller
Trap to kernel calls library
3 Trap code in register ◻ Library sets up trap, calls
User
space 8 OS
2
◻ OS handles system call
4 Increment SP 9 7
Call read ◻ Control returns to library
1 Push arguments ◻ Library returns to user
User program
Sys
Kernel code
Dispatc 5 6 call
space
h handle
(OS)
r
0
System calls for files & directories
Call Description
fd = open(name,how) Open a file for reading and/or writing
s = close(fd) Close an open file
n = read(fd,buffer,size) Read data from a file into a buffer
n = write(fd,buffer,size) Write data from a buffer into a file
s = lseek(fd,offset,whence) Move the “current” pointer for a file
s = stat(name,&buffer) Get a file’s status information (in buffer)
s = mkdir(name,mode) Create a new directory
s = rmdir(name) Remove a directory (must be empty)
s = link(name1,name2) Create a new entry (name2) that points to the
same object as name1
s = unlink(name) Remove name as a link to an object (deletes
the object if name was the only link to it)
 More system calls
CS 1550,
cs.pitt.edu
(originaly
modified by
Ethan L. Miller
and Scott A.
Brandt)

Call Description
pid = fork() Create a child process identical to the
parent
pid=waitpid(pid,&statloc,options) Wait for a child to terminate
s = execve(name,argv,environp) Replace a process’ core image
exit(status) Terminate process execution and return
status
s = chdir(dirname) Change the working directory
s = chmod(name,mode) Change a file’s protection bits
s = kill(pid,signal) Send a signal to a process
seconds = time(&seconds) Get the elapsed time since 1 Jan 1970

61 Chapter 1
A simple shell
while (TRUE) { /* repeat forever */
type_prompt( ); /* display prompt */
read_command (command, parameters) /* input from terminal */

if (fork() != 0) { /* fork off child process */

/* Parent code */
waitpid( -1, &status, 0); /* wait for child to exit */
} else {
/* Child code */
execve (command, parameters, 0); /* execute command */
}
}
Monolithic OS structure
Main
procedur
e

Service
routines

Utility
routines
 Virtual machines
App1 App2 App3
System calls Linux Windows NT FreeBSD
I/O instructions VMware VMware VMware
Calls to simulate I/O Linux
“Real” I/O instructions Bare hardware
◻ First widely used in VM/370 with CMS
◻ Available today in VMware
Allows users to run any x86-based OS on top of Linux or NT
◻ “Guest” OS can crash without harming underlying OS
Only virtual machine fails—rest of underlying OS is fine
◻ “Guest” OS can even use raw hardware
Virtual machine keeps things separated
 Microkernels (client-server)
Termina
Client Client Process File Memory
l … User mode
process process server server server
server
Microkernel Kernel mode

◻ Processes (clients and OS servers) don’t share memory

Communication via message-passing
Separation reduces risk of “byzantine” failures
◻ Examples include Mach