You are on page 1of 94

Computer Science 4500

Operating Systems
Module 1
Introduction, Overview and History
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 1

Welcome!
Welcome to Operating Systems. This course is designed to
introduce you to the fundamentals of operating systems. The
course uses specific features of real operating systems to
illustrate and reinforce the fundamental concepts.
Prerequisites include a good knowledge of data structures and
computer organization. You should also have had reasonable
experience with assembler language programming for some
contemporary processor (e.g. IBM S/390 or Intel X86,) and
strong skills in the C or C++ programming language. C is the
programming language of choice, and it is used in all code
illustrations. While not required, a course in digital design will
prove helpful.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 2

In This Module
Basic material about the course
The study of operating systems
The OS API and the user interface
Processor modes
Computer system and OS history

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 3

Programming Assignments
Programming assignments are used to reinforce the
concepts you learn in this course. There are three basic
types of assignments possible:
illustration of various system calls for one or more real
operating systems,
implementation of OS algorithms and simulation of
their effect, and
implementation of OS algorithms in the context of a
toy operating system, or a real system with readily
available source code (e.g. Linux, FreeBSD).
Your instructor will provide complete details on each of the
programming assignments you are to complete for the
course.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 4

Quizzes and Examinations


In addition to the programming assignments,
quizzes and examinations provide feedback on
your mastery of fundamental operating
system concepts. The number of quizzes and
examinations in this offering of the course is
described in the course notes provided by the
instructor.

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 5

Reference Textbooks
There are many good operating system textbooks available
and your instructor may expect you to use one with these
modules. Some of these texts are
Operating Systems Design and Implementation (third
edition), by Tanenbaum and Woodhull (Prentice Hall,
2006).
Operating Systems (third edition), by Deitel, Deitel, and
Choffnes (Addison-Wesley, 2003).
Operating Systems: Internals and Design Principles,
(sixth edition) by Stallings (Prentice Hall, 2008).
Operating System Concepts (eighth edition), by
Silberschatz, Galvin, and Gagne (Wiley, 2008).
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 6

The study of operating systems


There are two major ways to study
operating systems:
by examining the way in which application
programs can use the operating system, or
by examining the implementation (the
algorithms, data structures, etc.) of the
operating system

We will do some of each of these in this


course.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 7

Operating System Functions

Operating systems have two major functions:


to manage the computer systems resources, and
to provide the functions used by application programs for
the use of complex, shared, or restricted resources.
What are these resources?
The hardware of the computer system comprises the most
obvious set of resources. This includes the central
processor(s), the primary memory, and all the hardware
associated with input/output. Well cover each of these in
detail in this course.
Information is another important resource. The content of
every file or data set must be managed by the operating
system. We will also cover this resource in detail.

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 8

Viewing an OS as a virtual machine


An easy way to view an operating system is as a virtual
machine that provides a convenient way for applications to
use resources.
A particular toy operating system provided with a textbook
has almost 3000 lines of complex C code for managing the
text-mode terminal (e.g. a monitor and keyboard on a PC).
Clearly we dont want application programs to include this
much code just to be able to read and write the terminal.
The virtual machine looks like any other computer system,
but you can think of it as having additional simplified
instructions (actually functions) that allow easier use of the
resources than if the bare machine was used.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 9

The Hierarchical View of a System


Computer systems include many layers of hardware and
software, and the operating system is just one of those
layers.
You may already be aware that many systems use
microprograms which essentially provide functions that
correspond to each machine language instruction. The code
in these functions manipulate the bare hardware to effect
the actions of the machine language instruction.
The operating system, as another layer, provides extended
instructions (functions) that provide easy access to, and
management of, the systems resources.
Application programs form a layer on top of the OS.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 10

10

A typical computer system


Games

Presentation
Software

Spreadsheet

Compilers

Command Line
Interpreters

Editors

Operating System
Machine Language
Microprogram
Bare hardware
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 11

11

The Application Programming Interface


Application programs utilize system resources by
invoking the operating system. Requests from
application programs are passed to the operating
system through the application programming interface
(API) provided by the operating system. Different
operating systems may have different APIs, but the
functions are frequently similar.
The API for an operating system is frequently called the
set of system calls for that operating system.
Some systems may provide multiple different APIs.
Examples of these include IBMs OS/390 and Microsofts
Windows NT.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 12

12

The User Interface


Some functions you might normally think of as
belonging to the operating system are actually just
application programs usually provided with the system.
The most significant example is the application that
provides you with your primary interface to the system.
This could be a text-oriented interface (as in MVS,
UNIX, or MS-DOS), or a graphical user interface (as in
Windows or the MAC OS).
These applications, regardless of how complex, are not
part of the operating system. They accept user input
(by using the OS API) and carry out commands (again,
by using the OS API as required).
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 13

13

Systems With No User Interface


To amplify the difference between the user interface and
the operating system, consider a microprocessor system
that you might find under the hood of a new car. If this
system is used to control the automobiles ignition, it is
highly unlikely that it has a user interface. But there are
still applications running on that microprocessor system
that use the CPU and memory resources, and that
perform input/output operations. And it likely has a
small operating system that provides an API for those
applications to use!

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 14

14

Input/Output Interfaces

Most input/output devices are connected to a computer


system through an interface called a device controller. These
may have associated device registers that appear as
locations in a memory space accessible by the central
processor. For example, to set a timer device it is necessary
to write to three byte-sized registers, one indicating the
timer mode, and the other two providing a 16-bit timer
interval.
Other systems (e.g. an IBM mainframe) may have device
controllers that are accessed through a special processor
called a channel. Separate programs (strangely called
channel programs) must be prepared for the channel to
execute.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 15

15

Processor Modes (States)

Some resources must be accessed only by the operating system


if order is to be preserved in a system. Consider the use of a
printer connected to a multiuser system. Clearly only one user
should be printing at a time.
Processors on modern systems will usually have at least two
processor modes, or states. The mode in which user programs
(applications) usually execute is called the user mode, or the
problem state. In this mode certain instructions (e.g. those that
access device registers) may not be executed. In the other
mode, called the kernel mode, or the supervisor state, all
instructions may be executed and all resources may be
accessed. Some systems (e.g. DEC VAX) may have more than
two processor states, but well only consider two in this course.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 16

16

Operating System History


A brief survey of operating system history will prove useful
in understanding modern systems. When doing this well
talk about generations of computer systems. Successive
generations are usually introduced when major
technological advances are made.
Generation 0, if you will, began with Charles Babbages
design for his analytical engine to be used in calculating
entries of mathematical tables. This first design for a
digital computing device was conceived in the early 1820s!
Additionally, Ada Lovelace (the daughter of Lord Byron),
was the first programmer for this device. The
programming language ADA was named after her.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 17

17

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 17.1

18

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 17.2

19

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 17.3

20

Half of Babbages
Brain and a Notebook
(in the Science
Museum, London)

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 17.4

21

Generation 1: 1945-1955
The equipment in the first generation of practical
computing hardware consisted of hard-wired
plugboards, enormously heavy mechanical devices, and
vacuum-tube implementation of logical circuits.
There were no operating systems, programming
languages or networks in this generation.
Punched cards were introduced in the early 1950s.
Each card, the same size as a U. S. dollar bill, contained
80 bytes of data. Many devices existed to process data
in this format, including keypunches (to enter data onto
the cards), card sorters, and listing devices.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 18

22

An 80-column Punched Card

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 18.1

23

Generation 2: 1955-1965
Perhaps the most important technological advance in this
generation was the invention of the transistor. Vacuum tubes,
previously used in computing devices, generate enormous
amounts of heat and consume lots of energy. In contrast,
transistors generate little heat and consume little energy. Since
transistors dont operate by burning themselves up (like light
bulbs), the reliability of systems was also greatly improved.
Previously a computer system was completely dedicated to one
user at a time, requiring lots of time to set up a computation,
debug and run it, and then clean up the system afterwards. In
this generation, the concept of a job, a deck of cards containing
commands and data, reduced this overhead time significantly.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 19

24

Generation 2: Typical Systems


After a job was prepared off-line on a keypunch, it was
submitted to the computer system, where it processed
as a unit with little or no operator intervention. After it
was completed, the next job could be immediately
started.
There were two basic types of computer systems in this
generation. Scientific machines (typified by the IBM
7094) were used, as expected for jobs requiring large
amounts of computation. Business machines (typified
by the IBM 1401) were used for jobs that were
input/output intensive, but required limited numbers of
calculations.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 20

25

An IBM 7094 System

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 20.1

26

An IBM 1401 System

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 20.2

27

Generation 2: Batch Processing


In a clever combination of scientific and business
systems, batch processing was used to speed job
processing. Batches of jobs (that is, multiple sequential
jobs) were first copied to magnetic tape on an IBM 1401.
The tape was then physically moved to the IBM 7094,
where the jobs were read and processed, one after
another. Reading from magnetic tape is much faster than
reading from punched cards. Output was written to
magnetic tape, and when the batch was finished, the
magnetic tape was moved back to the IBM 1401, where
the printed output was copied from tape to paper (or
punched cards).
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 21

28

Generation 2: A Typical Job


A typical job included a combination of control cards and
data (that is, program source statements and data).
Control cards could be distinguished by the presence of
a special character in the first few columns. Control
cards were used to define the beginning of a job,
request the execution of a program, or to define a
collection of data to be used by a program.
The typical programming languages in use during this
generation were FORTRAN and COBOL. Operating
systems included IBSYS and FMS.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 22

29

Generation 3: 1965-1980
The major hardware development that introduced the third
generation was the integrated circuit. Instead of using discrete
components (transistors, resistors, etc.) to build a system, welldefined logical circuits were constructed as a single component.
This resulted in smaller and more power-efficient systems.
Another major architectural change united the features of
scientific and business computer systems. Instead of two
different machines (i.e. scientific and business), a single system
providing features of both types of machines was introduced.
The most popular of these was the IBM 360. Multiple models
this system was produced, varying in speed and features. Many
other manufacturers also produced similar systems.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 23

30

An IBM 360 System

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 23.1

31

Generation 3: OS/360
Perhaps the most important operating system prevalent in the
third generation was IBMs OS/360. It was designed to
successfully accommodate the needs of all users on every
model of the S/360 computer system. This goal was never
completely achieved.
The OS/360 operating system included millions of lines of
assembler code written by thousands of programmers. It isnt
surprising, then, that the numbers of bugs in the system
remained essentially constant, even over many releases.
Even so, OS/360 satisfied the needs of almost all customers.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 24

32

Generation 3: New OS Features


Multiprogrammingallowed multiplexing of execution (on
the CPU) with input/output operations. This required
partitioning memory into regions, each of which contained
one program.
Spoolinginput/output from executing programs was
from/to disk files; these files were copied from/to physical
devices (card readers and printers). SPOOL is an acronym
for simultaneous peripheral operations on line.
Timesharingmultiple users at on-line terminals could
edit, compile, and test small programs while batch
programs ran in the background.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 25

33

Generation 3: New Architecture


During this generation, DEC (Digital Equipment Corp.)
introduced the PDP-1, a system based on a new
architecture. PDP is an acronym for Programmed Data
Processor. The PDP-1 was notable for its relatively small
size and cost, and enabled computer systems to be
employed in many environments where larger systems
would be too costly. This machine was the first of a
series, terminating with the PDP-11. Machines like these
were called minicomputers.

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 26

34

Generation 3: New OS Designs

MULTICSMultiplexed Information and Computing Service.


MIT, Bell Labs, and GE developed the idea of a computing
utility (like a power plant) that could serve large numbers of
users; MULTICS introduced many seminal ideas in system
design.
The UNIX operating system from AT&T/Bell Labs.
Source code for early versions was licensed and widely
used in university courses.
Later versions (V7 and later) were restricted.
Other similar systems (notably FreeBSD, Linux, and
MINIX) are freely available in source code form.
The POSIX standard for UNIX-like systems was developed
by IEEE.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 27

35

Generation 4: 1980...
The development of large scale integrated circuits (LSI)
containing thousands of transistors and other components
enabled the development of complete processors in a
single circuit package. These microprocessor devices have
revolutionized computing, especially as additional
development led to very large scale integrated circuits
(VLSI) using complementary metal oxide semiconductor
(CMOS) technology containing hundreds of thousands,
even millions, of transistors.
Families of processors have been produced, starting with
small 4-bit systems. Today 64-bit microprocessor systems
are commonplace.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 28

36

Generation 4: New Peripherals


The fourth generation also saw the introduction of new
low-cost peripherals especially useful for small computer
systems. Examples include widespread use of graphic
displays and input devices, and increasingly smaller disk
systems, including removable media like floppy disks.
Another device with enormous impact is the network,
which enables communication between computer systems.
A major outgrowth of microprocessors and networking is
the Internet. Indeed, the Internet might be correctly
perceived as marking the beginning of a new generation of
computer systems.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 29

37

Generation 4: New Operating Systems


Widespread use of microprocessors spurred the development
of new operating systems. Some of the more notable of these
are
MS-DOS
Microsoft Windows and the Macintosh OS
UNIX is still popular in the fourth generation. High-end
workstations and supercomputers almost always use UNIX,
and Linux is gaining popularity, especially since it is now
available for many architectures, including S/390 mainframes.
IBMs OS/390 is the latest mainframe operating system, and
includes a traditional UNIX API, accompanied by the usual
UNIX utilities and shells.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 30

38

Next
In the next module well look at two
major operating system concepts:
processes and files.
Various system calls for managing
processes will be examined, and actual
programs using these system calls will
be developed.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 31

39

CSCI 4500
Operating Systems
Module 2
OS Concepts: Processes and File Systems
Updated: July 30, 2014
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 1

In This Module
Operating System Concepts
Introduction to Processes
Files and Data Sets
Name Binding, Catalogs and Directories
System Calls for Processes and Tasks
Sample Programs Using Processes
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 2

Operating System Concepts


Recall that we will study operating systems from
two points of view. These are the views of
Application writers, using the various system calls to
achieve interaction with the system and its
resources.
OS implementers, who must write the code for the
operating system that implements the system calls.

Lets consider two major system call categories,


those for processes and for file systems.

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 3

Introduction to Processes (Tasks)


A process, sometimes called a task, is
essentially a packaged unit of work for a
computer system. In many cases when you
enter a command or double click on an icon,
a command interpreter process (a shell) will
create a new process to run the program.
Processes will always have
an address space in which they can execute, and
a set of processor registers to hold data, next
instruction address, and so forth.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 4

Processes
In a multiprogramming system, multiple
processes (at least one per user) are being
virtually executed. But its obvious only one
process can be actually executed at a time on a
single processor.
Thus, the process currently being executed is
occasionally freeze dried and another process
is executed for a while. This is called a context
switch, since the processors context changes.
When a process is not being executed, salient
details (e.g. CPU register contents and file
pointers) are stored away in a process table.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 5

Process Example: The CPU


executes some instructions from
process A
LOAD A
ADD B .
STORE C .
DIV X
.
ADD Z
STORE Y

Process A

2008 Stanley A. Wileman, Jr.

LOAD K
DIV E
MPY T
STORE N
CMP L
JNE LOOP

Operating Systems

Process B

Slide 6

then saves process As context


and executes some instructions
from process B
LOAD A
ADD B
STORE C
DIV X
ADD Z
STORE Y

Process A

2008 Stanley A. Wileman, Jr.

LOAD K
. DIV E
. MPY T
. STORE N
CMP L
JNE LOOP

Operating Systems

Process B

Slide 7

then saves process Bs context,


restores As context and executes
some more instructions.
LOAD A
ADD B
STORE C
DIV X
ADD Z
STORE Y

Process A

2008 Stanley A. Wileman, Jr.

LOAD K
DIV E
MPY T
STORE N
CMP L
JNE LOOP

.
.
.
Operating Systems

Process B

Slide 8

System Calls for Processes


Key process-related system calls include
those in the following categories:
create or terminate a process;
cause a process to wait, if necessary, until it can
use a particular resource;
manage the memory used by a process; and
control the handling of asynchronous signals sent
to a process.

We will later examine some of these system


calls in detail, and use them in a program.

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 9

Process Tables
A process table has one entry for every
process in the system.
Each process table entry contains
information about process ownership,
relation to other processes, process state,
and statistical information.
Process tables are frequently organized
as static arrays.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 10

10

Process Identification and Ownership


Each process in a system must be uniquely
identified. In UNIX systems, this identification
is provided by an integer called the process ID.
Each process is also owned by a particular user,
identified by a user ID (uid).
One uid, associated with the super user,
imparts special privileges (e.g. shutdown the
system, and read arbitrary files) to processes.
(OS/390 UNIX allows multiple super users.)
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 11

11

Files and Data Sets


Another major operating system function is to
provide convenient access to information
organized in files, or data sets. (The term data
set is frequently used for files on mainframes.)
Files are named collections of information,
usually stored on disk or magnetic tape.
Files can also be stored on other devices,
including RAM disks and removable memory
cards for use with portable devices (e.g.
cameras and handheld computers).
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 12

12

File Systems
A file system is a storage structure (like a
data structure, but normally tailored for a
secondary storage device like a disk).
There are many different types of file
systems, even for the same operating
system. Speed, reliability, media type, and
other factors influence the design of a file
system. For example, CD Rom file systems
differ considerably from those for hard drives.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 13

13

System Calls for File Manipulation


The usual system calls for manipulating files
include the following:
open prepare a file for input/output
read copy data from file to memory
write copy data from memory to file
close conclude I/O operations on a file

Other system calls may be provided for things like


file locking, random positioning, concurrent I/O,
tape positioning, communication functions, and so
forth.
We will later take a detailed look at a number of
these system calls and use them in a program.

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 14

14

Organizing Files
Even systems designed for use by a single
user may have thousands of files. How are
these files organized?
Most systems use a hierarchical naming
scheme for files. A particular file is accessed
by giving first the name at the top level of the
hierarchy, then the second level name, and
so forth, finishing with the name of the
desired file.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 15

15

Hierarchical Naming Examples


A mainframe computer might use names like
STANW.SAMPLE.JOBS and
STANW.SAMPLE.CLIST for data sets
containing different types of sample code.
If these were stored in a UNIX file system,
they might be /u/stanw/sample/jobs and
/u/stanw/sample/clist.
Note that the basic concepts are the same.
Its much like describing a path through a
tree, from the root to a particular node.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 16

16

Binding
The term binding is used to indicate the
mechanism by which a name is associated
with an object.
For file systems, binding refers to the
mechanism used to associate a name with a
file.
There are many different binding techniques
used in different file systems.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 17

17

Binding Examples
The IBM MVS system uses catalogs, each of
which stores pairs of the form (name, location),
where name might be STANW.SAMPLE.JOBS and
location would identify the physical location of the
file.
UNIX systems use multiple directories are used to
store this information, each directory similar to an
interior node of a tree. Thus each directory entry
(called a link) contains one component of a
hierarchical name and a reference to the named
object, which could be another directory or a
regular file.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 18

18

Catalogs
STANW.SAMPLE.JOBS
STANW.SAMPLE.CLIST
.
.
.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 19

19

Directories
u
stanw

stanw
sample

sample
jobs
clist

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 20

20

Catalogs and Directories


We frequently say a catalog or directory
contains a group of files, but this is only a
conceptual idea.
As we have seen, a directory or catalog only
contains a list of file identifiers and other
information, but not the files themselves.
Directories and catalogs are usually themselves
stored in files, but with limited access for writing
since their organization must be carefully
maintained. This is crucial for the proper
operation of the file system.

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 21

21

Common Filesystems
Some common file systems include:
FAT (used with MS-DOS)
NTFS (used with Windows NT)
CDFS (used on CD-ROMs)
UFS (used with UNIX systems)
HFS (used with OS/390 UNIX)
MVS (used with mainframe systems)

Each of these has a unique way of naming and


storing files, and mapping from a file name to its
storage. The functions they provide, however,
are basically the same.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 22

22

Hierarchical File System Conventions


The top directory (node) in a hierarchical file
system tree is called, naturally, the root node or
root directory.
This concept does not apply to the MVS file
system. MVS may, however, have multiple
catalogs, the first of which is called the master
catalog.
The first component of a data sets name in MVS
is called the high level qualifier (HLQ).
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 23

23

Relative and Absolute Path Names


In many systems (UNIX, Windows, etc.), a
unique file can be identified by giving a path to
it, starting from the root directory. This is
called an absolute, or complete path path to the
file.
A path may be given from a working directory,
which is just a directory identified as such by
the user. A default working directory, called the
users home directory, is in effect at login time.
Absolute paths always begin with /; a relative
path is one that does not start with /.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 24

24

Example Paths
Absolute or complete paths
/u/stanw/samples/jobs
/usr/man/man2/fork.2
Equivalent relative paths (where cwd means
current working directory)
jobs (with cwd of /u/stanw/samples)
man2/fork.2 (with cwd of /usr/man)

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 25

25

System Calls for Directories


Windows NT:

CreateDirectory, RemoveDirectory
GetCurrentDirectory, SetCurrentDirectory

UNIX:

mkdir, rmdir
link, unlink, mount, unmount
chdir, chroot

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 26

26

Non-Hierarchical File Systems


Some file systems do not support hierarchical
file naming (in the traditional manner).
For example, the CP/M operating system (the
predecessor of MS-DOS) only allows each file
to have 11 characters in its file name, in the
common 8.3 format (e.g. computer.txt).
There is only one directory, which contains an
entry for every file in the CP/M file system.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 27

27

File Permissions
Most systems provide some protection for files
to restrict who can read, write, create, or
delete particular files.
UNIX systems use a 9-bit code containing
three groups (for the user/owner, the users
group, and all others) of 3 bits each.
Each group of bits is interpreted as r w x. If r
is set, then reading is allowed; w = write; x =
execute.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 28

28

RACF (pronounced Rack F)


OS/390 provides optional security systems
(like RACF) that provide security external to
the file system. Each system call that seeks
to access an object (e.g. a file) causes the
operating system to query RACF to see if the
requested access is permitted.
This global approach to providing security is
different (and much more comprehensive)
than the file-system integral approach used
by UNIX.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 29

29

Access Control Lists


Windows NT and RACF also provide
ACLs, or Access Control Lists.
An ACL is a list of pairs, each pair
identifying a user or group of users, and
the type of access permitted to the file.
Each file system object may have an
associated ACL. RACF extends ACLs to
virtually every object in the system.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 30

30

Special Files
UNIX allows access to physical devices (for
suitably privileged processes) using the same
I/O system calls used for regular files.
Character special files are used to model
devices that do transfer one character at a
time. Examples include serial ports, mice,
keyboards, printers, etc.
Block special files model devices that transfer
a block of data at a time (disks and tapes).
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 31

31

File Descriptors / Handles


Opening a file requires specification of the file
name, or the path to the file. The type of access
desired (e.g. read, write) is also indicated.
After the file is open, other system calls
referencing the file use a reference to a data
structure containing information about the open
file; this reference is returned by the open call.
In UNIX, this reference is called a file descriptor.
In Windows, it is called a handle. And in MVS it is
a pointer to a data control block.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 32

32

Files Automatically Open in


UNIX Processes
Three (or more) files are usually
available (opened automatically) when
a process begins execution:
Standard input (usually the keyboard)
Standard output (usually the CRT)
Standard error (usually also the CRT)
Standard print (in MS-DOS and Windows)
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 33

33

High Level Language I/O


In a high-level language (like C or Pascal),
application programs rarely directly use the
reference returned by the open system call.
Instead, they use a reference to a higher-level
data structure managed by standard libraries
provided by the language.
For example, to read a character c from the
keyboard in C, we could use either
read (0, &c, 1);
(using the system call)
c = getchar(stdin); (using a standard library function)
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 34

34

Pipes
A pipe is essentially queue of bytes treated as an
I/O device.
When a pipe is created, the user is usually given
two handles (or file descriptors).
The first handle is used for reading, and the
second handle is used for writing.
Data written into the pipe is conceptually written
at the tail of the queue; reading from the pipe
removes data from the head of the queue.
Pipes are frequently used for communication
between processes.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 35

35

Implementation of System Calls


Q. Since the operating system code usually
executes in kernel mode, and applications
run in user mode, how can an application
make a system call which requires the
application to enter the kernel mode?
A. Special instructions are used that cause
traps - just as in a divide by 0, but these
traps indicate to the OS that a system call
was made. While in kernel mode, the
application can only execute the specified
system calls code, thus ensuring security.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 36

36

Making System Calls from C


Rather than have users struggle with writing
special trap instructions, libraries are included
with C implementations that define functions
that execute the appropriate trap instructions.
Example (UNIX):
char buffer[80];
int count;
count = read (0,buffer,80);
The read function handles parameter passing
and arranges for the appropriate trap instruction
to be executed.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 37

37

System Call Results


Most system calls are designed to return a
unique code indicating failure. In UNIX, this is
usually 1.
When a system call fails, an additional
mechanism is available to identify the particular
reason for failure:
errno (a global variable in UNIX)
GetLastError (a function call in WindowsNT)
a processor registers contents in MVS
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 38

38

Command Interpreters (Shells)


Character-oriented interfaces to operating
systems (as opposed to GUIs) utilize one or
more programs that interpret a command
language, frequently resulting in requests to
create processes and execute programs.
These interpreters are normally called shells
(e.g. sh, csh, mush, tcsh and ksh in UNIX).
Windows NT uses a program called cmd.exe,
and MS-DOS uses command.com.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 39

39

Typical Features of Shells


A user-configurable prompt is issued to
indicate the shell is ready for the next
command.
prog arg1 arg2 would be typed to request
creation of a process for execution of the
executable program in file prog (a relative
path) with arguments arg1 and arg2 (more
on arguments later).
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 40

40

More Shell Features


prog < input executes prog with its standard
input redirected to the file input.
prog > output redirects standard output to
the named file.
prog < input > output redirects both
standard input and standard output.
prog1 | prog2 runs prog1 and prog2; the
standard output of prog1 piped to prog2s
input.
prog & runs prog concurrently with shell.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 41

41

Other Approaches
Note that the mechanism by which an
executable program is submitted for execution,
and how external objects (e.g. files and
terminals) are associated with the process, is
usually independent of the system calls made by
the process.
For example, in MVS, program execution is
requested by statements in a data set (file)
containing JCL (job command language). The
program itself, while unchanged, could have its
execution requested by a command line in UNIX.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 42

42

MVS Job Control Language


JCL statements usually have three fields: a label, a
statement type, and parameters.
The JOB statement is used to define a job consisting
of one or more job steps:
//DOIT
JOB
ACCT#,USERNAME
The EXEC statement requests the execution of a
program:
//STEP1 EXEC PGM=COMPILER
The DD statement associates a ddname with a
data set (the ddname is referenced inside the
program):
//SYSIN DD DSN=MY.SOURCE.PROGRAM
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 43

43

A Typical MVS Job


//DOIT
//

JOB

EXEC

12345678,USERNAME
COB2UCLG

//COB2.SYSIN DD *
The COBOL program goes here
/*
//GO.OUT DD SYSOUT=*
//GO.IN DD DSN=MY.INPUT.DATA,DISP=SHR

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 44

44

The UNIX fork System Call


The UNIX system call fork() duplicates the
process that executes it: memory contents,
open file handles, quotas, permissions, etc.
In the parent (creating) process, fork()
returns the unique process id (an integer) of
the newly created process.
In the child process, fork() returns 0.

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 45

45

The UNIX execve System Call


The execve() system call replaces the core
image (memory contents) of the currently
executing process with that of another
program.
Shells begin the execution of a program
(specified on the command line) by first
executing fork, and then arranging for the
child process to exec the appropriate
program.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 46

46

The Windows NT CreateProcess


System Call
The CreateProcess system call combines
the effects of the UNIX fork and exec
system calls.
CreateProcess creates a new process
which begins executing a named
program with a specified set of
arguments.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 47

47

The MVS ATTACHX System Call


The ATTACHX system call is used in MVS to
create a new subtask (process) and have it
execute a named program.
MVS System calls are usually made from code
generated by assembler macros.
The ATTACHX macro places the address of a
parameter block in a register, then executes
the instruction SVC 42 which invokes the
operating system by causing a trap.
The parameter block includes the name of
the program to be executed by the new task.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 48

48

Passing Arguments to UNIX Processes


When a UNIX process begins execution, it
receives command line parameters in a
variable length array of pointers to character
strings.
In C, the main function uses two (or three)
arguments:
An integer giving the number of arguments
A pointer to an array of character strings which
contains the arguments
The third argument points to the environment
(which we will cover later).
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 49

49

Sample Program Using Arguments


The program args.c illustrates a C program
that references the arguments provided on
the command line.
The program just prints the arguments.
If invoked as args one two three, the
program will print the following:
Number of arguments = 4
Argument 0: <args>
Argument 1: <one>
Argument 2: <two>
Argument 3: <three>
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 50

50

UNIX program: args.c


/************************************/
/* Print the command line arguments */
/************************************/
#include <stdio.h>
main (int argc, char *argv[])
{
int i;
printf("Number of arguments = %d\n, argc);
for (i=0;i<argc;i++)
printf("
Argument %d: <%s>\n",i, argv[i]);
exit(0);
}

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 51

51

Sample Program Using Fork/Exec


The program prun.c illustrates a C program
that creates a new process that then executes
a named program with arguments.
If invoked as prun pargs one two, the
program will create a new process (using
fork()) and terminate. The new process
will then execute the pargs program (using
execve()) which will print the expected
output.

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 52

52

UNIX program: prun.c (part 1)


/*********************************************/
/* Create a new process to execute a program */
/*********************************************/
#include <stdio.h>
extern char **environ;
void main( int argc, char *argv[])
{
char *args[10];
int i;
/* Eliminate argv[0] prior to use by execve */
for (i=1; i<argc;i++) args[i-1] = argv[i];
args[i-1] = NULL;
if (argc < 2) {
/* error: too few arguments */
printf("Usage: prun <prog> <arg> ...\n" );
exit(1);
}
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 53

53

Program: prun.c (part 2)


if (fork() == 0) { /* fork, test for error */
/* inside the new process, execute the prog */
execve(argv[1], args, environ);
perror("execve");
/* if execve had error */
exit(1);
}
printf( "prun complete.\n", i );
exit(0);
}

2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 54

54

Next
In the next module well examine the process
model in more detail.
We will examine the states in which
processes may exist, and the causes for
transitions between these states.
Threads will be considered as alternatives to
processes.
And interprocess communication (IPC) will be
introduced.
2008 Stanley A. Wileman, Jr.

Operating Systems

Slide 55

55