Lecture 1


Course webpage

http://csserver.evansville.edu/~hwang/s11-courses/cs470.html

Handouts, assignments
Syllabus and schedule, textbook
Monday, January 10
CS 470 Operating Systems - Lecture 1
1
Outline

What is an Operating System?

History of OS's

OS services

System startup

OS interface

OS design

Virtual machines
Monday, January 10
CS 470 Operating Systems - Lecture 1
2
Introduction


Three main areas drive research in computer
improvements:

Architecture

Operating systems

Programming languages
Innovations in each area drive the others
Monday, January 10
CS 470 Operating Systems - Lecture 1
3
What is an OS?

An operating system is the intermediary
between hardware and user software that
makes a computer usable. It is implemented in
firmware and/or software.
User
Applications
OS
Hardware
Monday, January 10
CS 470 Operating Systems - Lecture 1
4
What is an OS?

Resource managers - goal of efficient use of
hardware


processes - execution, synchronization,
communication

memory - caching, swapping

storage - file systems, disks

I/O - buffering, drivers
Protection & security
Monday, January 10
CS 470 Operating Systems - Lecture 1
5
What is an OS?

User interface - goal of usability for users



Windows/(pre-OS X) Mac GUIs - Windows grew to
include the web browser until lawsuit, smartphone
OS's headed that way again.
Unix/Mac OS X shells - actually a user-levell
program, but must have one
Other areas have been included
Monday, January 10
CS 470 Operating Systems - Lecture 1
6
History of OS's - 1940's



Hardware and OS development are linked
closely starting in the 1940's.
First computers had no OS and were very hard
to program. Manually/mechanically load all
instructions (e.g., using toggle switches) of an
application.
Soon came the resident loader (a simple OS
loaded once and always in the machine until
next reboot), paper tape/cards, assembly
language.
Monday, January 10
CS 470 Operating Systems - Lecture 1
7
History of OS's - 1940's


The loader simply loaded the instructions from
a program and started it. Only one process
running on the entire machine with access to
everything, including the parts with the resident
loader.
Enter dual mode operation


User mode for user processes
Kernel mode for the OS. Also called supervisor,
system, privileged, or monitor mode.
Monday, January 10
CS 470 Operating Systems - Lecture 1
8
History of OS's - 1940's



In dual mode, instructions are divided into
ordinary and privileged. Allow only the OS to
execute privileged instructions.
When user processes attempt to execute a
privileged instruction (called a system call), it
is trapped by the OS, checked for validity, then
executed on behalf of the user process.
Examples: I/O requests, timer requests, etc.
Dual mode generally is supported in hardware
with an instruction mode bit.
Monday, January 10
CS 470 Operating Systems - Lecture 1
9
History of OS's - 1950's


During the 1950's, computing was single
stream, batch processing. One job (process)
is executed at a time in the order received.

Read tape/cards

Execute program

Print results on tape/cards/printer
No user interaction; output in minutes, hours, or
days. CPU waited for I/O, so added a disk to
spool jobs. Still used for printers.
Monday, January 10
CS 470 Operating Systems - Lecture 1
10
History of OS's - 1960's


During the 1960's, realize that the CPU could
be executing another program when waiting for
I/O.
Batch multiprogramming combined several
jobs together to be loaded and then run. Still
no user interaction, but the OS scheduled CPU
among the jobs in the batch for better
utilization.
Monday, January 10
CS 470 Operating Systems - Lecture 1
11
History of OS's - 1960's



The late 1960's brought time-sharing systems.
These systems are multi-tasking, multi-user,
and support interactive users that wait for
"immediate" system response. Key systems
included: CTSS, Multics, TSS, CP/CMS → VM
OS switches rapidly between jobs and users
giving each the appearance of being a single
process/user. This is supported in hardware by
a timer interrupt.
Virtual memory and file systems also developed
Monday, January 10
CS 470 Operating Systems - Lecture 1
12
History of OS's - 1970's, 1980's



1970's combined batch and time-sharing
systems into multimode systems. E.g. Unix.
Also the development of networking: Ethernet
and LANs, ARPANET→Internet; remote
computing
1980's emphasized user convenience and
responsiveness. Workstations and PCs - going
back to single computer dedicated to a single
user.
Monday, January 10
CS 470 Operating Systems - Lecture 1
13
History of OS's - 1980's

The late 1980's brought two similar, but
different innovations.



Distributed systems - loosely-coupled,
independent computers that co-operate. Clientserver or peer-to-peer models.
Parallel systems - tightly-coupled, single-controller
systems executing symmetrically or asymmetrically.
Increased throughput, economy of scale, increased
reliability, graceful degradation.
Monday, January 10
CS 470 Operating Systems - Lecture 1
14
History of OS's - 1990's


The 1990's combined distributed and parallel
systems into clustered systems. Each
machine is independent, but highly-connected
(usually with a dedicated LAN) often with a
single controller. E.g., Beowulf cluster.
Led to blade servers (multiple motherboards in
a single chassis) and now many core machines
like the UE "supercomputer".
Monday, January 10
CS 470 Operating Systems - Lecture 1
15
History of OS's - 2000's



Current development is at two ends of the
spectrum.
Embedded smartphone OS's - single user,
limited in resources, a lot like the first OS's!
Grid/cloud computing


Paradigms for organizing distributed computing
Goal is to make systems easier to use, OS support
for abstracting away the infrastructure
Monday, January 10
CS 470 Operating Systems - Lecture 1
16
OS Services

Process management (Ch. 3-7)


Memory management (Ch. 8-9)


Process creation, scheduling, synchronization, and
communication
Programs must be in memory to execute, but main
memory is too slow for all accesses, and too small
and volitile to store all programs.
Storage management (Ch. 10-12)

How to organize non-volitile storage for the
convenience of users
Monday, January 10
CS 470 Operating Systems - Lecture 1
17
OS Services

I/O peripheral management (Ch. 13)


Devices and device drivers
Protection and security (Ch. 14-15)

Protection: ensure only authorized users do only
authorized activities

Security: prevent unauthorized access

Need both to be safe
Monday, January 10
CS 470 Operating Systems - Lecture 1
18
System Startup

How does an OS start running? Bootstrap
program is put in a known location.


E.g., MBR of first disk - Windows loader or lilo/grub
Also need to be able to find interrupt handlers.
Information usually in a fixed location as an
interrupt vector table indexed by device
number.

E.g., Intel IRQ's
Monday, January 10
CS 470 Operating Systems - Lecture 1
19
OS Interface



How do we interact with an OS?
Users - command interpreters (i.e., a shell) or a
GUI. Unix GUIs are on top of shells.
Programmers - system call API. System calls
look like function calls, but often are written in
assembly and cause OS traps for service. E.g.,
Unix file management (in C):
fd = open ("filename", ...);
num_read = read (fd, buffer, num_bytes);
Monday, January 10
CS 470 Operating Systems - Lecture 1
20
OS Interface

Another example is the Windows windowing
API. Programming languages often provide a
higher level API to OS services. E.g., file
access in C++:
fstream file ("filename", ...);
file >> buffer;

These are wrappers to low-level system calls
that present an easier to use interface and error
checking.
Monday, January 10
CS 470 Operating Systems - Lecture 1
21
OS Design

An OS is a large, software engineering
problem! Some issues include:

Hardware

Type of system


User goals - easy to learn and use, reliable and
safe, fast
System goals - easy to design, maintain, operator;
flexible, reliable, efficient
Monday, January 10
CS 470 Operating Systems - Lecture 1
22
OS Design


OS design history is similar to software
development in general. Tension between
abstraction and modularity vs. efficiency.
It is also like organizational behavior history.
Control oscillates between centralization and
decentralization of control.
Monday, January 10
CS 470 Operating Systems - Lecture 1
23
OS Design - Layered Approach


Early OS's were monolithic programs. Very
fast, but hard to develop and modify. Various
approaches to modularization
Layered approach: hardware (layer 0) to user
applications (layer n)


Completely specifying interface between layers
allows each one to be written and tested separately
Problem is that OS does not break down into
definite layers well. E.g., disk management - file
system vs. backing store
Monday, January 10
CS 470 Operating Systems - Lecture 1
24
OS Design - Microkernels

Microkernels (e.g., Mach, original WinNT):
only the absolute minimum necessary services
are in the OS kernel.


Everything else runs in user space as system
services between the kernel and the application.
Problem is that communication overhead between
user space and kernel space creates a tendency to
want to put more into the kernel.
Monday, January 10
CS 470 Operating Systems - Lecture 1
25
OS Design - Modules

Modules (e.g. Linux, Solaris, Mac OS X): use
object-oriented techniques to organize services



Core module is like a microkernel
Dynamically load and link other service modules as
needed. Get a structure that looks more like a
graph.
Easy to modify, but more efficient since all services
run in kernel space
Monday, January 10
CS 470 Operating Systems - Lecture 1
26
Virtual Machines


Suppose we take the layered approach to its
logical extreme and just say that the OS API is
just the layer under the user application. I.e.,
the OS API describes a virtual machine.
Then we can run multiple copies or even
different OS's on top of this layer.
Monday, January 10
CS 470 Operating Systems - Lecture 1
27
Virtual Machines
User
User
User
VOS
VOS
VOS
VM
VM
VM
Native OS
Hardware
Monday, January 10
CS 470 Operating Systems - Lecture 1
28
Virtual Machines



Why create a VM?
Isolation - each "user" has its own VM, so no
protection worries with user code
Run multiple OS's



Old binaries - DOS, Mac 68000, Atari, Commodore
New binaries - Parallels desktop for Mac OS X,
Windows, Linux
Cross-platform portability. E.g., Java VM
bytecodes, .NET Framework CLR
Monday, January 10
CS 470 Operating Systems - Lecture 1
29