Input Output Subsystems - Operating Systems - Lecture Notes, Study notes of Operating Systems

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

2012/2013

Uploaded on 04/23/2013

ashalata
ashalata 🇮🇳

3.8

(18)

106 documents

1 / 32

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
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
IO_subsystems Page 1
Docsity.com
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20

Partial preview of the text

Download Input Output Subsystems - Operating Systems - Lecture Notes and more Study notes Operating Systems in PDF only on Docsity!

 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