CS 326 Operating Systems Fall 2004 Professor Allan B. Cruse University of San Francisco
Feb 04, 2016
CS 326Operating 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/Odevice
I/Odevice
I/Odevice
I/Odevice
. . .
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
Hardware
Operating System software
Application software
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
Hardware
Application ApplicationApplication
Shared Runtime Librariesuser-mode
supervisor-mode
System Call Interface
Device Driver Components
memorymanager
taskmanager
filemanager
networkmanager
OS Kernel
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
IDE Controller
CPU
system bus
Slave Drive(Drive 1)
Master Drive(Drive 0)
optional
Memory
Some IDE Device Registers
Command Register 8-bits, write-onlyport 0x01F7
Status Register 8-bits, read-onlyport 0x01F7
Drive-Head Register 8-bits, read/writeport 0x01F6
Error Register 8-bits, read-onlyport 0x01F1
Data Register 16-bits, read/writeport 0x01F0
NOTE: Not shown are several additional special-purpose IDE device-registers.
IDE Drive-Head Register
1 L 1 DRV(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 busyDRDY = Controller is ready for new commandDF = Drive Fault occurredDSC = Seek operation has completedDRQ = Data-Transfer RequestedCORR = Data-Error was correctedIDX = Index Mark is detectedERR = Error information available
IDE Error Register (0x1F1)
BBK UNC MC IDNF MCR ABRT TK0NF AMNF
Legend:BBK = Bad Block detectedUNC = Uncorrectable Data-Error MC = Media ChangedIDNF = ID Mark Not FoundMCR = Media Change RequestedABRT = Command was AbortedTK0NF = Track 0 Not FoundAMNF = 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 idnumberexecute 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)