Modern Operating Systems: Design Principles and Programming

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

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

3. 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)

4. 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

5. 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

6. 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

7. Computer Hardware Components CPU Memory system bus I/O device I/O device I/O device I/O device . . .

8. 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

9. 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

10. System Organization Application software Operating System software Hardware

11. 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’

12. 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

13. 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!

14. 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

15. 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

16. 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

17. ‘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

18. 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

19. The IDE Controller Memory CPU system bus IDE Controller Master Drive (Drive 0) Slave Drive (Drive 1) optional

20. Some IDE Device Registers Data Register 16-bits, read/write port 0x01F0 Command Register port 0x01F7 8-bits, write-only 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 NOTE: Not shown are several additional special-purpose IDE device-registers.

21. 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)

22. IDE Status Register (0x1F7) BSY DRDY DF DSC DRQ CORR IDX ERR 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

23. IDE Error Register (0x1F1) BBK UNC MC IDNF MCR ABRT TK0NF AMNF 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

24. 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)

25. 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

26. 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)

27. 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

28. 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)