Pardon the Interruption
Interrupt handlers are an integral part of most device drivers. Learn to implement interrupt handlers and bottom halves.
Saturday, July 15th, 2006
Due to the indeterminate nature of I/O and speed mismatches between I/O devices and the central processing unit, devices request the processor’s attention by asserting certain hardware signals asynchronously. These hardware signals are called interrupts.
Each interrupting device is assigned an associated identifier called an Interrupt ReQuest number, or IRQ. When the processor detects that an interrupt has been generated on an IRQ, it abruptly stops what it’s doing and invokes an Interrupt Service Routine (ISR) registered for the corresponding IRQ. ISRs (also called interrupt handlers) execute in a special kernel context called the interrupt context and are an integral part of most device drivers.
This month, let’s learn the art of designing interrupt handlers using the example of a roller wheel device found in many cordless phones. You’ll also learn to use kernel mechanisms like tasklets for offloading heavy work from interrupt handlers.
The Interrupt Context
An interrupt handler is a critical piece of code that converses directly with the hardware. An interrupt handler is given the privilege of instant execution in the larger interest of system performance. However, if the interrupt handler isn’t quick and lightweight, it contradicts the overall design of the system.
To be pardoned for rudely interrupting the current thread of execution, interrupt handlers have to politely execute in a restricted environment called an interrupt context. Here’s a guide to interrupt handler etiquette (do’s and don’ts for code executing in interrupt context):
