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) Webpage: cs.usfca.edu/~cruse

Course Textbooks William Stallings, Operating Systems: Internals and Design Principles (5 th 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 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 Shared Runtime Libraries user-mode supervisor-mode System Call Interface Device Driver Components memory manager task manager file manager network manager 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-only port 0x01F7 Status Register 8-bits, read-only port 0x01F7 Drive-Head Register 8-bits, read/write port 0x01F6 Error Register 8-bits, read-only port 0x01F1 Data Register 16-bits, read/write port 0x01F0 NOTE: Not shown are several additional special-purpose IDE device-registers.

IDE Drive-Head Register 1L1 DRV (0/1) HS3HS2HS1HS0 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) BSYDRDYDFDSCDRQCORRIDXERR 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) BBKUNCMCIDNFMCRABRTTK0NFAMNF 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)