Transcript CS 326 Operating Systems - USF Computer Science Department

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
device
I/O
device
I/O
device
...
I/O
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 devicecontrol 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
manager
task
manager
file
manager
network
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
(Drive 0)
Slave Drive
(Drive 1)
optional
Some IDE Device Registers
port 0x01F0
Data Register
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
16-bits, read/write
NOTE: Not shown are several additional special-purpose IDE device-registers.
IDE Drive-Head Register
1
L
1
DRV
(0/1)
HS3
HS2
HS1
Legend:
L = Linear Addressing (1=yes, 0=no)
DRV = Drive selection (0=Master, 1=Slave)
HS3..HS0 = Head Selection (0..15)
HS0
IDE Status Register (0x1F7)
BSY
DRDY
DF
DSC
DRQ
CORR
IDX
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
ERR
IDE Error Register (0x1F1)
BBK
UNC
MC
IDNF
MCR
ABRT
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
TK0NF AMNF
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)