
























Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Main points of this lecture are: Input Output Subsystems, Producer-Consumer Architecture, Idea of Descriptor, Kernel Descriptor, Process Descriptor, Descriptors and Entities, Process View of Devices, Driver Table, File Pointer, Buffering
Typology: Study notes
1 / 32
This page cannot be seen from the preview
Don't miss anything!

























we've studied concurrency in detail. we've studied producer/consumer in detail.
we know how a producer/consumer architecture avoids deadlock and avoids races.
NOW: take that knowledge, forget about MECHANISM, and utilize a p/c model (with all the semaphores and mutexes intact) as a model for what happens at the higher levels.
A few asides Whenever I say "producer-consumer" , presume adequate locking for bounded- buffer case, including "block on full" behavior.
whenever I say "array" in the following lecture, read that as "sparse array" or "hash"!
Structure is "simple", provided that we describe it at the highest possible level.
But getting adequate performance requires lots of tricks that make it seem complex!
Warnings: Input/output Thursday, December 02, 2004 2:07 PM Docsity.com
A producer-consumer architecture Write to file or device: queues output. Read from file or device: consumes input. How is this accomplished? Key idea: I/O descriptors I/o subsystem identity of device any special features required of device description of queued data Contains everything needed to implement producer-consumer relationships kernel descriptor : (integer) pointer to entry in kernel I/o table. process descriptor : pointer to entry in process's I/o table. This points to a kernel descriptor! Two kinds: Idea of a descriptor a process I/O descriptor is created, which points to a kernel descriptor, which points to a driver entry, which contains the information to talk to the device. When you say open("file", MODE), a process file pointer is initialized, which points to a process buffer, which refers to process I/O descriptor, which points to a kernel I/O descriptor, When you say fopen("file", "mode") I/O subsystem Thursday, December 02, 2004 2:07 PM Docsity.com
If two processes open the same file or device, they get the same kernel descriptor. The mapping between kernel descriptors and entities is one-to-one. I/O tables Thursday, December 02, 2004 2:07 PM Docsity.com
Process view of devices: There is a many-one relationship between Processes A and Kernel Descriptors B Process view Thursday, December 02, 2004 2:07 PM Docsity.com
stores functions and data shared for each "kind" of device. Driver table stores concept of device state for a specific device. globally valid numbering Kernel descriptor 0: standard input 1: standard output 2: standard error stores link from process to kernel descriptor, which contains actual information. local numbering Process descriptor stdin: fileno(stdin)== stdout: fileno(stdout)== stderr: fileno(stderr)== stores concept of process buffering and state. local thing, fflush() flushes the buffer. File pointer: I/O concepts Thursday, December 02, 2004 2:07 PM Docsity.com
some devices want to talk in large blocks, and are more efficient doing so => kernel-level buffering I collect info one byte at a time, e.g. fprintf(file, "some junk\n"); □ □ I write in, say, 4096-byte chunks. examples: disk writes (tape writes). Programs want to minimize system calls. □ Store the output of fprintf() in a large buffer. We flush when it gets to set size, using write() to flush it. □ Result: minimal calls to write => minimal system call overhead. □ □ Read is similar! □ Aside: you can control this behavior with fcntl() □ This is called " block buffering ". example: in writing large files, make lots of calls to fprintf(), and then one call to write() basic idea: buffering Kernel-level producer-consumer ("block device") Process-level buffering: formatted i/o. Note: two distinct kinds of buffering Buffering Thursday, December 02, 2004 2:07 PM Docsity.com
Driver table structure Thursday, December 02, 2004 2:07 PM Docsity.com
determines the "kind" of device. determines which functions to call to manipulate it. Major number of device determines which device of a kind. E.g., if there are several disks, there is one major number, several minor numbers. Minor number of device Concept of major and minor numbering Major/minor numbering Thursday, December 02, 2004 2:07 PM Docsity.com
list of kernel descriptors in use by the process. converts from local to global numbering an array of integer offsets into the kernel descriptor table. Process I/o descriptor table Process descriptor table Thursday, December 02, 2004 2:07 PM Docsity.com
Pointer to a buffer within the process. Contains data to be read or written. "Formatted I/O" Contains a pointer to process descriptor table. Process file pointer (FILE *) Process file pointer Thursday, December 02, 2004 2:07 PM Docsity.com
Why so many layers? Answer: lots of cases: Buffering to/from a file is separate from interaction with the file. Can have two buffers active for one file. minimize system calls/kernel mode switches. Why are there file pointers? Two processes can share access to one file. One process can refer to a single file via multiple paths. One logical scheme covers all processes. (If you dup a file 5 times, all descriptors are interchangeable!) Why are there process file descriptors? Need somewhere to store state for the thing that's open. This is independent of the "kind of thing" This allows powerful performance enhancements. Why are there kernel file descriptors? Need somewhere to store how to interact with Why are there driver tables? Layers? Thursday, December 02, 2004 2:07 PM Docsity.com
Need somewhere to store how to interact with "kinds" of things. This is independent of the state of the thing. Docsity.com
One contact point for each device. Processes not allowed to do their own I/O. Operating system maintains state of each device. Chained access to devices by tables that point to tables. Principles of UNIX I/O design Pointers to function for all functions required of a driver. Kernel driver table: list of all drivers. Data used by drivers to keep track of device state. Kernel device table: list of data for devices in use. File can be a device or a disk file (which is sort of a pseudo-device) Coordinates sharing and multiple opens of files, etc. Kernel file descriptor table: list of attributes of all open files, including files treated as devices. Allocated by open Deallocated by close Maintains state of a file. Actually just a reference to kernel table. Almost no process-specific state in it. Process file descriptor table: list of pointers from process objects (0-1023) to kernel objects. Created by fopen Process formatted I/O buffers: Principles of UNIX I/O Thursday, December 02, 2004 2:07 PM Docsity.com
Created by fopen Destroyed by fclose FILE *, contains pointer to process descriptor table. Local to process, not shared. Docsity.com