UQC 113 S 2 Interrupt driven IO Interrupt

UQC 113 S 2 Interrupt driven IO

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

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