cs 326 operating systems
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
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)