2
How to provide interfaces
Rough reading guide (no exam guarantee):
Tanenbaum Ch. 5.1 – 5.5 & 6.1-3Silberschatz Ch. 13 & 10.1-4, 11.1-8
Also: Patterson Ch. 8 (I/O)
3
I/O
• A computer without peripheral devices is pretty much useless
• Old mainframes required kernel-recompile to install new devices
• Now: PCs have millions of possible devices
4
Goals for I/O Handling
• Enable use of peripheral devices
• Present a uniform interface for– Users (files etc.)– Devices drivers
• Hide the details of devices from users (and OS)
5
Device Controllers
• I/O devices have components:– mechanical component
– electronic component
• The electronic component is the device controller– may be able to handle multiple devices
– OS deals with controllers not devices
• Controller's tasks– convert bit stream to block of bytes
– perform error correction as necessary
– make blocks available to main memory
6
Relevant Device Properties (1)
• The mechanical/electronic properties of devices impact software– timing (seek times etc.)– interrupts– data rates
8
Accessing Devices (1)
• Most devices provide– buffers (in / out)– control registers– status registers
• These are accessed from the OS/Apps– I/O ports– memory-mapped– hybrid
10
Memory-Mapped I/O
+ No special instruction in assembler needed
+ No special protection needed (remember VM)
+ Testing control registers directlyNot load and test!
- Caching of control registers?
- One bus?
13
Shuffling Data
• Data needs to be sent– one byte at a time– several bytes at a time
• Using the CPU to shuffle small amounts of data may be inefficient Direct Memory Access (DMA)
15
Interrupts Revisited
Connections between devices and interrupt controller actually use interrupt lines on the bus rather than dedicated wires
16
Goals of I/O Software (1)
• Device independence– programs can access any I/O device – without specifying device in advance
• (file on floppy, hard drive, or CD-ROM)
• Uniform naming– name a file or device as a string or an integer– not depending on which machine
• Error handling– handle as close to the HW as possible
17
Goals of I/O Software (2)• Synchronous vs. asynchronous transfers
– blocking transfers vs. interrupt-driven– OS may make interrupt-driven operations look like
blocking to the user
• Buffering– data coming off a device cannot be stored in final
destination– OS should buffer for pre-processing/RT..
• Sharable vs. dedicated devices– disks are sharable– tape drives would not be– OS should be able to support both
18
I/O
There are three kinds of I/O handling
• Programmed I/O– “Do it all yourself”
• Interrupt-driven I/O– “Here you are, now tell me when its done”
• DMA-based I/O– “Let someone else do it”
20
Interrupt-Driven I/O
Writing a string to the printer using interrupt-driven I/O
Code for system call Code for interrupt handler
21
I/O Using DMA
• Printing a string using DMAa) code executed when the print system call is made
b) interrupt service procedure
23
Interrupt Handlers (1)
• Interrupt handlers are best hidden– have driver starting an I/O operation block until
interrupt notifies of completion
• Interrupt procedure does its task– then unblocks driver that started it
24
Interrupt Service RoutineSteps that must be performed in software when interrupt
occurs (no complete list)
Step 1: Preparation1. Save regs not already saved by interrupt hardware2. Set up context for interrupt service procedure3. Ack interrupt controller, reenable interrupts ()Step 2: Actual task execution1. Copy registers from where saved2. Run service procedure 3. Schedule and run a new process (+ new context)
25
Interrupt Handlers (3)
• Interrupt handlers should be fast (why?)
• Sometimes there is a lot of things to do– Copying buffers, waking up processes, starting new I/O
ops, etc.
• Solution: split in two parts– Top half: disabled interrupts, only essential work
– Bottom half: enabled interrupts, does most of the work
26
Device Drivers (1)
• Logical position of device drivers is shown here• Communication between drivers and device controllers over the bus
27
Device Drivers (2)
• Classically we distinguish two types– Block devices (disks..)– Character devices (keyboards, printers..)
• Handles (typically)– Abstract requests “reads” and “writes”– Communication with device controller– Initialization– Power management
28
Device-Independent I/O Software (1)
Functions of the device-independent I/O software
Uniform interfacing for device drivers
Buffering
Error reporting
Allocating and releasing dedicate devices
Providing a device-independent block size
Generic I/O management in the kernel
29
Uniform Interfacing for Device Drivers
(a) Without a standard driver interface
(b) With a standard driver interface
30
Device-Independent I/O Software (3)
• How are devices addressed?
• UNIX/Linux– Major number
• Identifying the device driver
– Minor number• Identifying the virtual device
31
Linux Driver Registration
• Drivers (modules) need to register with the kernel
• Kernel keeps table of drivers
• Special kernel routines for adding/deleting entries
32
Buffering
• Where to put the buffers– User– Kernel
• What if the buffer is full?
• How many buffers?
• When to tell the user app?
33
Device-Independent I/O Software
(a) Unbuffered input(b) Buffering in user space(c) Buffering in the kernel followed by copying to user space(d) Double buffering in the kernel
34
I/O Buffering
• Where to store data to be sent?– User buffer
• Locking?
• When finished?
– Kernel buffer• No locking
– Device controller
37
More I/O
• Read more about disks, clocks, terminals etc. in Tanenbaum
• Disks:– Slow– Block size (transfer unit)
• Read about RAID 0-5! (Tanenbaum 302-306)– Covered in the exercise
39
File Systems
• UNIX: Everything is a file!
• Main memory is not enough– Persistency– Not large enough– Need a structuring of “data”
40
Long-term Information Storage
1. Must store large amounts of data2. Information stored must survive the termination of
the process using it3. Multiple processes must be able to access the
information concurrently
Store information on disks and other external media in units called files
Filesystem: OS Part that manages files
42
File StructureThree common ways how OS structures files
a) byte sequenceb) record sequencec) Tree (records of varied length, key field)
43
File Types• Regular Files
– ASCII– binary
(a) executable (b) archive
• Directories• Character special
files• Block special files
44
File Access• Sequential access (early OS)
– read all bytes/records from the beginning– cannot jump around, could rewind or back up– convenient when medium was magnetic tape
• Random access (modern OS)– bytes/records read in any order– essential for many app., e.g., database– read can be …
• move file marker (seek) and then read, or
• read and then move file marker
46
File Operations
1. Create
2. Delete
3. Open
4. Close
5. Read
6. Write
7. Append
8. Seek
9. Get attributes
10.Set attributes
11.Rename
12.Lock
49
Memory-Mapped Files
• Accessing files using read/writes is sometimes cumbersome
• Alternative: map the whole file in memory
• Access the memory directly
50
Memory-Mapped Files
(a) Segmented process before mapping files into its address space
(b) Process after mapping existing file abc into one segment
creating new segment for xyz
52
Directory Structure
• Notice the difference between Windows and UNIX– Windows: different partitions (volumes) are
visible (A:,B:,C:, …)– UNIX: filesystems are mounted in one
directory tree