CS 326

Operating Systems
Fall 2004
Professor Allan B. Cruse
University of San Francisco
 Instructor Contact Information
• Office: Harney Science Center – 212
• Hours: M-W 2:45-3:15, Tu-Th 1:30-2:30
• Phone: (415) 422-6562
• Email: [email protected]

• Webpage: cs.usfca.edu/~cruse
 Course Textbooks
• William Stallings, Operating Systems:
Internals and Design Principles (5th Ed),
Pearson Prentice-Hall, Inc (2005)

• Gary Nutt, Kernel Projects for Linux,

Addison-Wesley Longman, Inc (2001)
 Course Synopsis
• We study modern operating systems:
– Design Issues
– Data structures
– Internal Algorithms
• We focus on microcomputer examples:
– MS Windows
– UNIX/Linux
• We do “hands-on” programming exercises
 Prerequisites
• Ability to do programming in C Language
• Understand Intel x86 Assembly Language
• Knowledge of Standard Data Structures
• Familiarity with basic UNIX commands

• This background corresponds to USF’s

freshman-sophomore course-sequence:
CS110, CS112, CS210, CS245
 Assigned Readings
• Week 1: read Gary Nutt’s “Overview”
• Weeks 2-14: read chapter from Stallings
(as specified in printed course-syllabus)

• Class Lectures will cover supplementary

material, intended to clarify ideas in texts
• Class Exercises will apply these general
principles by doing practical programming
Computer Hardware Components

CPU
Memory

system bus

I/O I/O I/O I/O

device device device
... device
 Background
• Earliest computer programs ran on a “bare
machine” (i.e., no separate OS software)
• These programs had to control I/O devices
as well as perform their computations
• But writing software to control devices is
very demanding on human programmers
(e.g., requires specialized knowledge of
each device’s design and idiosyncrasies)
• Tediously repetitive for each new program
 Solution: software ‘reuse’
• It was crazy to rewrite the complex device
control software over and over again with
for every new computing task
• Better to separate the specialized device-
control software from the application code
• The ‘old’ device-control software could be
reused with a ‘new’ application – provided
there was a way to ‘link’ the two together
• This insight was the genesis for the OS
System Organization

Application software

Operating System software

Hardware
 Modern Operating Systems
• Several ambitious goals for today’s OS’s
• Allow multiple application programs to be
executed at the same time, each sharing
access to the devices, yet not interfering
with one another (i.e., protection)
• Allow multiple users on the same system
• Provide fairness in system access policies
• Support ‘portability’ and ‘extensibility’
 A Modern OS Design
Application Application Application

Shared Runtime Libraries

user-mode
supervisor-mode

System Call Interface

memory task file network

manager manager manager manager

Device Driver Components

OS Kernel

Hardware
 Linux Device Programming
• Application programs normally are not
allowed to program I/O devices directly
• But Linux lets ‘privileged’ users disable
this built-in ‘protection’ feature
• We can take advantage of this capability,
to show exactly what’s involved in writing
software that directly controls i/o hardware
• This gives insight into what an OS does!
 Device Characteristics
• Each device-type involves different details
• But most have a few aspects are common
• There’s a way for the CPU to issue device
commands (e.g., turn device on/off, etc)
• There’s a way for the CPU to detect the
device’s current status (e.g., busy, ready)
• There’s a way to perform transfers of data
• There’s a way the device can send signals
 I/O Ports
• On Intel x86 systems (such as ours):
– CPU communicates with devices via ‘ports’
– Ports provide access to device-registers
– So ‘ports’ are similar to memory-locations
– Ports have addresses, and can store values
– Special instructions exist for accessing ports
– The ‘IN’ instruction reads from a port
– The ‘OUT’ instruction writes to a port
– On a PC, port-addresses are 16-bit numbers
Important example: Hard Disks
• Our classrooms and labs have PCs that
use IDE fixed-disks for storage of files
• IDE means ‘Intelligent Drive Electronics’
• The programming interface for IDE drives
conforms to an official documented ANSI
standard (American National Standards
Institute)
• We present enough details for an example
 ‘IDENTIFY DRIVE’
• There exist about 40 different commands
(e.e., read, write, seek, format, sleep, etc)
• Some are ‘mandatory’, others ‘optional’
• An example: the ‘Identify Drive’ command
• It provides information on disk’s geometry
and some other operational characteristics
• It identifies the disk’s manufacturer and it
provides a unique disk serial-number
 IDE Command Protocol
• IDE Commands typically have 3 phases:
– COMMAND PHASE: CPU issues a command
– DATA PHASE: data moves to/from IDE buffer
– RESULT PHASE: CPU reads status/errors
 The IDE Controller
CPU Memory

system bus

IDE Controller

Master Drive Slave Drive

(Drive 0) (Drive 1)
optional
 Some IDE Device Registers
port 0x01F0 Data Register 16-bits, read/write

port 0x01F7 Command Register 8-bits, write-only

port 0x01F7 Status Register 8-bits, read-only

port 0x01F6 Drive-Head Register 8-bits, read/write

port 0x01F1 Error Register 8-bits, read-only

NOTE: Not shown are several additional special-purpose IDE device-registers.

IDE Drive-Head Register

DRV
1 L 1 (0/1)
HS3 HS2 HS1 HS0

Legend:
L = Linear Addressing (1=yes, 0=no)
DRV = Drive selection (0=Master, 1=Slave)
HS3..HS0 = Head Selection (0..15)
IDE Status Register (0x1F7)

BSY DRDY DF DSC DRQ CORR IDX ERR

Legend:
BSY = Controller is busy
DRDY = Controller is ready for new command
DF = Drive Fault occurred
DSC = Seek operation has completed
DRQ = Data-Transfer Requested
CORR = Data-Error was corrected
IDX = Index Mark is detected
ERR = Error information available
IDE Error Register (0x1F1)

BBK UNC MC IDNF MCR ABRT TK0NF AMNF

Legend:
BBK = Bad Block detected
UNC = Uncorrectable Data-Error
MC = Media Changed
IDNF = ID Mark Not Found
MCR = Media Change Requested
ABRT = Command was Aborted
TK0NF = Track 0 Not Found
AMNF = Address Mark Not Found
 COMMAND PHASE
• Wait until the IDE controller is ‘not busy’
• Disable interrupts (to prevent preemption)
• Confirm ‘drive ready’ status
• Issue the ‘IDENTIFY DRIVE’ command
(i.e., output byte 0xEC to port 0x01F7)
 DATA-TRANSFER PHASE
• Continuously poll the Status Register until
the DRQ bit is set, indicating that the data
has been transferred into the controller’s
internal ‘sector-buffer’ (size is 256 words)
• Read the IDE Data-Register 256-times,
saving the values into a memory area
 RESULT PHASE
• Verify that the DRQ status-bit is now clear,
indicating Data-Transfer Phase is finished
• Check the ERR status-bit, to see if errors
occurred, and if so, read the Error Register
to obtain details about what went wrong
• Re-enable interrupts (so multitasking can
resume)
 Demo: ‘idnumber.cpp’
• On our course website is a demo-program
that uses the IDE ‘Identify Drive’ command
to obtain and print the Disk Serial-Number
• You can compile and execute this program
on your student workstation:
compile using: $ make idnumber
execute using: $ ./idnumber
• Everyone will see a different serial-number
 In-class Exercise
• You can add your own code to this demo,
so it will display useful information about
the disk’s storage capacity and geometry
• You’ll need some ANSI documentation
• Try showing:
– Number of Disk Cylinders
– Number of Disk Heads
– Number of Sectors-per-Track
– Total disk storage-capacity (in megabytes)