Operating Systems Design and Implementation Chapter 03 (version - PDF document

Operating Systems Design and Implementation Chapter 03 (version January 30, 2008 ) Melanie Rieback Vrije Universiteit Amsterdam, Faculty of Sciences Dept. Computer Science Room R4.23. Tel: (020) 598 7874 E-mail: melanie@cs.vu.nl, URL: www.cs.vu.nl/ ∼ melanie/ 01 Introduction 02 Processes 03 Input/Output 04 Memory Management 05 File Systems 00 – 1 / Input/Output • Principles of I/O hardware • Principles of I/O software • Deadlocks • Lots of MINIX 03 – 1 Input/Output/

Input/Output Basic idea: I/O devices are attached to a computer and are available to programs by means of an inter- face. It is the interface that we’re interested in here. Note: Interfaces hide differences between similar de- vices (you don’t care whether you have an IDE or SATA hard disk). • Character devices: all I/O occurs as a sequen- tial stream of bytes: read( out data ); write( in data ); • Block devices: all I/O occurs in units of randomly accessible blocks of bytes: read( in block_number out data ); write( in block_number, in data ); Note: Distinction is often blurred, e.g. is a tape a block device or not? Others don’t fit, e.g. clocks. 03 – 2 Input/Output/3.1 Principles I/O Hardware Device Controllers (1/3) Basic function: controllers sit between the mechan- ical hardware device and the rest of the computer: they offer an electronic interface in the form of reg- isters . By writing values into these registers the controller subsequently puts the device into action. Results of a device operation are returned in registers as well. 03 – 3 Input/Output/3.1 Principles I/O Hardware

Device Controllers (2/3) Question: how do we make that interface available to programs. • Memory-mapped I/O: the registers of the con- troller are mapped (by the hardware) into addresses of main memory. mov 23, DATA ; copy data to register ; at address #23 • I/O mapped I/O: all I/O registers are contained in a separate address space that can only be ac- cessed through special I/O instructions: mov dx, PORT ; Register address = port mov ax, VALUE ; Register value out ; Set the register. 03 – 4 Input/Output/3.1 Principles I/O Hardware Device Controllers (3/3) When I/O is finished, most controllers generate an in- terrupt . Each controller has an associated interrupt vector . The interrupt vector is an index in a table containing pointers to interrupt handlers . There is one interrupt handler per controller. An interrupt handler is a procedure that is to be exe- cuted when an interrupt occurs. interrupt vector interrupt handler 03 – 5 Input/Output/3.1 Principles I/O Hardware

Direct Memory Access Drive 1. CPU� DMA� Disk� Main� programs� controller controller memory CPU the DMA� Buffer controller Address Count Control 4. Ack 2. DMA requests� Interrupt when� transfer to memory 3. Data transferred done Bus The internal buffer at the I/O Controller is needed to smoothen the transfer of data between the (disk)device and main memory: • The controller catches the data on the device as a constant bit stream, which are fed into the buffer. • The buffer is checked for errors (checksum). If okay, then data is transferred to memory. The transfer between controller and memory is de- pendent on the availability of the bus: we can’t wait for that once a data transfer has been issued — you need a buffer. 03 – 6 Input/Output/3.1 Principles I/O Hardware Principles of I/O Software (1/2) • Device independence: The I/O software should provide a level of abstraction that allows programs to make use of I/O facilities that are independent of particular devices or even interfaces. • Naming: The identification/name of a device should be supported in such a way that it is independent of the device itself. • Error handling: Errors should be corrected (if possible) nearest to their source ⇒ don’t just de- tect them and say something went wrong, but do something about it. 03 – 7 Input/Output/3.2 Principles I/O Software

Principles of I/O Software (2/2) • Blocking vs. interrupts: We want a simple model. A process that does I/O issues a request, waits for I/O to complete, and continues ⇒ synchronous data transfer . Lower levels have a simplistic model: start the de- vice; go ahead as if nothing happened; just catch the interrupt later on ⇒ asynchronous model . We’ll have to implement the synchronous one on top of the asynchronous model. • sharable vs. dedicated: The software has to make the distinction between devices that can be shared (disks), and those that can not (printers). The user doesn’t care: as long as the transfer suc- ceeds as expected. Solution: structure I/O software into layers: (1) inter- rupts, (2) drivers, (3) device-independent I/O, (4) user space I/O. 03 – 8 Input/Output/3.2 Principles I/O Software Interrupt Handlers 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 1 0 1 0 0 0 0 0 0 0 1 2 0 0 0 0 0 1 0 0 0 0 1 1 0 0 0 0 0 1 0 0 interrupt vector 3 0 0 0 1 0 0 1 0 0 0 0 1 0 0 0 1 0 0 1 0 4 0 0 1 0 1 1 0 1 0 0 1 1 0 0 1 0 1 1 0 1 0 0 0 0 0 1 0 1 5 0 1 1 1 0 1 0 1 0 1 1 1 0 1 1 1 0 1 0 1 6 1 0 1 0 0 1 0 1 0 0 1 1 1 0 1 0 0 1 0 1 interrupt 7 1 0 1 0 0 1 0 1 0 1 0 0 1 0 1 0 0 1 0 1 8 1 1 1 0 1 1 0 1 1 0 1 0 1 1 1 0 1 1 0 1 register 0 1 1 1 0 1 0 1 0 1 1 1 0 1 1 1 0 1 0 1 program counter Basics: the interrupt handler does what is strictly nec- essary to ensure that the next I/O operation can be executed: • Results of the last I/O operation are safely stored. • It unblocks the driver/task who was waiting for the I/O operation to complete. 03 – 9 Input/Output/3.2 Principles I/O Software

Device Drivers process read/ UPPER HALF write read/ request write request handler pool query/ update device admin. query/ update device interrupt handler handler LOWER HALF I/O controller Question: What’s the difference between the upper and lower half? Question: What’s in the device administration? 03 – 10 Input/Output/3.2 Principles I/O Software Device-Independent I/O Software Basic idea: The device-independent software pro- vides an interface to higher layers that completely hides all I/O specific aspects. • Device naming, e.g., by using major and minor device numbers. • Protecting devices against access by unauthorized processes/users. • Handling different block sizes for different devices. • Provide buffering mechanisms for data blocks (soft- ware cache). • Manages block devices, e.g. by keeping track of which blocks of a block device are still available. • Allocates/deallocates dedicated devices to users. • Takes care of proper error handling. Question: To what extent is this software itself device independent? 03 – 11 Input/Output/3.2 Principles I/O Software

User Space I/O Idea: You can actually do better by providing your own view on what I/O looks like. These solutions are im- plemented completely on top of an operating system and are independent of any device. Example: The C standard I/O library: extern FILE *fopen(const char *, const char *); extern int fclose(FILE *); extern int fflush(FILE *); extern int fprintf(FILE *, const char *, ...); extern int fscanf(FILE *, const char *, ...); extern int printf(const char *, ...); extern int scanf(const char *, ...); extern int sprintf(char *, const char *, ...); extern int fgetc(FILE *); extern char *fgets(char *, int, FILE *); extern int fputc(int, FILE *); extern int fputs(const char *, FILE *); extern int getc(FILE *); ... Question: Is this actually operating system stuff? 03 – 12 Input/Output/3.2 Principles I/O Software User Space I/O – Daemons daemon ordinary process lpr paper.ps lpr OS Idea: In order to properly manage some resource (e.g. a printer), only one special process is allowed to do actual I/O requests for that device. All other pro- cesses have their I/O requests propagated to the dae- mon. Note: This type of I/O can be structured completely independently of an operating system 03 – 13 Input/Output/3.2 Principles I/O Software

I/O Layering I/O� Layer reply I/O functions User processes Make I/O call; format I/O; spooling� I/O� request Device-independent� Naming, protection, blocking, buffering, allocation� software Device drivers Set up device registers; check status� Interrupt handlers Wake up driver when I/O completed� Hardware Perform I/O operation Note: We’ve just discussed this layering from bottom to top. 03 – 14 Input/Output/3.2 Principles I/O Software Deadlock Examples: • Four cars at a junction arrive at the same time. All have right of way, and politely wait for the other to continue. • Five philosophers sit at a round table with one fork between each plate. They all start to eat by lifting their left fork... • Process A opens file #1, and then attempts to open file #2 which is currently opened by process B . Process B , meanwhile, waits until it can open file #1. Definition: A set of processes are in deadlock if each process is waiting for an event to happen that only another process in that set can cause. 03 – 15 Input/Output/3.3 Deadlock