CS162 Operating Systems and Systems Programming Lecture 17 Disk Management and File Systems March 18, 2010 Ion Stoica http://inst.eecs.berkeley.edu/~cs162Lec 17.2 3/18/10 CS162 ©UCB Spring 2010 Review: Want Standard Interfaces to Devices • Block Devices: e.g. disk drives, tape drives, Cdrom – Access blocks of data – Commands include open(), read(), write(), seek() – Raw I/O or file-system access – Memory-mapped file access possible • Character Devices: e.g. keyboards, mice, serial ports, some USB devices – Single characters at a time – Commands include get(), put() – Libraries layered on top allow line editing • Network Devices: e.g. Ethernet, Wireless, Bluetooth – Different enough from block/character to have own interface – Unix and Windows include socket interface » Separates network protocol from network operation » Includes select() functionality – Usage: pipes, FIFOs, streams, queues, mailboxesLec 17.3 3/18/10 CS162 ©UCB Spring 2010 Review: How Does User Deal with Timing? • Blocking Interface: “Wait” – When request data (e.g. read() system call), put process to sleep until data is ready – When write data (e.g. write() system call), put process to sleep until device is ready for data • Non-blocking Interface: “Don’t Wait” – Returns quickly from read or write request with count of bytes successfully transferred – Read may return nothing, write may write nothing • Asynchronous Interface: “Tell Me Later” – When request data, take pointer to user’s buffer, return immediately; later kernel fills buffer and notifies user – When send data, take pointer to user’s buffer, return immediately; later kernel takes data and notifies userLec 17.4 3/18/10 CS162 ©UCB Spring 2010 Goals for Today • Finish Discussing I/O Systems – Hardware Access – Device Drivers • Disk Performance – Hardware performance parameters – Queuing Theory • File Systems – Structure, Naming, Directories, and Caching Note: Some slides and/or pictures in the following are adapted from slides ©2005 Silberschatz, Galvin, and Gagne Note: Some slides and/or pictures in the following are adapted from slides ©2005 Silberschatz, Galvin, and Gagne. Many slides generated from lecture notes by Kubiatowicz.Lec 17.5 3/18/10 CS162 ©UCB Spring 2010 Main components of Intel Chipset: Pentium 4 • Northbridge: – Handles memory – Graphics • Southbridge: I/O – PCI bus – Disk controllers – USB controllers – Audio – Serial I/O – Interrupt controller – TimersLec 17.6 3/18/10 CS162 ©UCB Spring 2010 Device Controller read write control status Addressable Memory and/or Queues Registers (port 0x20) Hardware Controller Memory Mapped Region: 0x8f008020 Bus Interface How does the processor talk to the device? • CPU interacts with a Controller – Contains a set of registers that can be read and written – May contain memory for request queues or bit-mapped images • Regardless of the complexity of the connections and buses, processor accesses registers in two ways: – I/O instructions: in/out instructions » Example from the Intel architecture: out 0x21,AL – Memory mapped I/O: load/store instructions » Registers/memory appear in physical address space » I/O accomplished with load and store instructions Address+ Data Interrupt Request Processor Memory Bus CPU Regular Memory Interrupt Controller Bus Adaptor Bus Adaptor Other Devices or BusesLec 17.7 3/18/10 CS162 ©UCB Spring 2010 Memory-Mapped Display Controller Example • Memory-Mapped: – Hardware maps control registers and display memory to physical address space » Addresses set by hardware jumpers or programming at boot time – Simply writing to display memory (also called the “frame buffer”) changes image on screen » Addr: 0x8000F000—0x8000FFFF – Writing graphics description to command-queue area » Say enter a set of triangles that describe some scene » Addr: 0x80010000—0x8001FFFF – Writing to the command register may cause on-board graphics hardware to do something » Say render the above scene » Addr: 0x0007F004 • Can protect with page tables Display Memory 0x8000F000 0x80010000 Physical Address Space Status 0x0007F000 Command 0x0007F004 Graphics Command Queue 0x80020000Lec 17.8 3/18/10 CS162 ©UCB Spring 2010 Transferring Data To/From Controller • Programmed I/O: – Each byte transferred via processor in/out or load/store – Pro: Simple hardware, easy to program – Con: Consumes processor cycles proportional to data size • Direct Memory Access: – Give controller access to memory bus – Ask it to transfer data to/from memory directly • Sample interaction with DMA controller (from book):Lec 17.9 3/18/10 CS162 ©UCB Spring 2010 Administrivia • Group Evaluations (Both Projects 1 and 2) – These MUST be done: you will get a ZERO on your project score if you don’t fill them out – We will be asking you about them, so make sure you are careful to fill them out honestly • Other things – Group problems? Don’t wait. – Talk to TA/talk to me » Let’s get things fixed!Lec 17.10 3/18/10 CS162 ©UCB Spring 2010 A Kernel I/O StructureLec 17.11 3/18/10 CS162 ©UCB Spring 2010 Device Drivers • Device Driver: Device-specific code in the kernel that interacts directly with the device hardware – Supports a standard, internal interface – Same kernel I/O system can interact easily with different device drivers – Special device-specific configuration supported with the ioctl() system call • Device Drivers typically divided into two pieces: – Top half: accessed in call path from system calls » implements a set of standard, cross-device calls like open(), close(), read(), write(), ioctl() » This is the kernel’s interface to the device driver » Top half will start I/O to device, may put thread to sleep until finished – Bottom half: run as interrupt routine » Gets input or transfers next block of output » May wake sleeping threads if I/O now completeLec 17.12 3/18/10 CS162 ©UCB Spring 2010 Life Cycle of An I/O Request Device Driver Top Half Device Driver Bottom Half Device Hardware Kernel I/O Subsystem User ProgramLec 17.13 3/18/10 CS162 ©UCB
View Full Document
Unlocking...