CS 326 Operating Systems Fall 2004 Professor Allan B. Cruse University of San Francisco.

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)