This is an excerpt from Jonathan S. Shapiro's article "Design Note: Kernel Interrupt and Concurrency Management"
With the exception of the interval timer interrupt and (on SMP systems) the interprocessor interrupt, Coyotos does not handle interrupts directly. Also, the kernel does not support interrupt nesting. Our working assumptions are:
- The longest kernel path is very short (units of microseconds).
- We can therefore defer doing anything about interrupts until we are just about to exit the kernel, when kernel state is not ``in flight.''
- Since we are going to defer interrupt handling to the scheduler, the kernel does not need to deal with nested interrupts.
- It is preferable, and not much unduly expensive, to prioritize interrupt handlers using the kernel scheduler rather than hardware priorities.
- If it were not for the need to deal with the interval timer interrupt and IPI issues, we could hypothetically run with interrupts entirely disabled in the kernel.
Ignoring the interval timer and the interprocessor interrupt, the primary action taken by the kernel in response to an interrupt is to wake up the relevant driver process by moving it from a per-interrupt stall queue to the ready queue. A preemption occurs only if the awakened process is higher priority than the currently executing process. On hardware platforms where a prompt hardware-level acknowledge is required to avoid interrupt controller lockup, the interrupt handler takes care of this as well.
