UQC113S2 Interrupt driven IO

We have already seen the hardware support required to facilitate interrupts We will now look at the higher levels of software required to support interrupt driven IO Much of what we will be looking at is really operating system material

Strategies for I/O handling Can be programmed or polled io –Is wasteful of cpu resources Can be interrupt driven –Is difficult for some devices Can use DMA –Is a mixture of polled and interrupt –Can be slow

Layers of Software for IO

Device Drivers We have already looked at the interrupt routines All the other hardware specific code is placed in the device driver These are normally either block or character orientated devices Can be generic for specific devices –ie all SCSI devices, disks, cd-roms.

Device Drivers Device Driver should offer –Uniform interface, all should be able to be read, written, opened and closed –Buffering capacity – this will vary per device –Error handling and reporting – should be graceful –Often should be hot swappable

Error Handling & Reporting Errors are much more common with IO than with anything else (except users!) There can be: programming errors –Asking a device to do something it can’t ie write to a mouse Actual I/O errors –Hard disk sector corrupted, disk not in drive, etc

Buffering Strategies

A unbuffered input –Inefficient, must re-start user process constantly B Buffering in user space –Users may not have correct control over buffer C Buffering in kernel + copy to user space –Efficient but what about overflow? D Double buffering in the kernel –The best!

I/O Functional layers

The structure of I/O systems