1 / 28

CS 326 Operating Systems

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

Leo
Download Presentation

CS 326 Operating Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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)

More Related