Interrupts are asynchronous events caused by external devices. They may occur at any time and are not associated in any way with the thread that is currently running.
The handling of interrupts is one of the more complex areas in RTOS design, largely because it is the least well defined. The ways in which interrupt vectors are named, how interrupts are delivered to the software and how interrupts are masked are all highly architecture- (and in some cases board-) specific. The approach taken in eCos is to provide a generalized mechanism with sufficient hooks for system-specific code to be inserted where needed.
Let us start by considering the issue of interrupt vectors. Hardware support differs greatly here: from the Intel Architecture and the 680X0 having support for vectoring individual interrupts to their own vectors, to most RISC architectures that only have a single vector. In the first case it is possible to attach an ISR directly to the vector and know that it need only concern itself with the device in question. In the second case it is necessary to determine which device is actually interrupting and then vector to the correct ISR. Where there is an external interrupt controller, it will be possible to query that and provide what is essentially a software implementation of hardware vectoring. Otherwise the actual hardware devices must be tested, by calling the ISRs in turn and letting them make the determination. Since it is possible for two devices to interrupt simultaneously, it is necessary to call all ISRs each time an interrupt occurs.
Interrupt masking has a similar variety of support. Most processors have a simple interrupt mask bit in a status register. The 680X0 has seven levels of masking. Any board with a interrupt controller can be programmed to provide similar multi-level masking. It is necessary to keep the interrupt masking mechanism simple and efficient, and use only architectural support. The cost of manipulating an on-board interrupt controller may be too high. However, individual device drivers may want access to their individual mask bits in the interrupt controller, so support for this must be provided.
Most of the infrastructure necessary for a (somewhat) portable treatment of interrupts is implemented in the eCos Hardware Abstraction Layer (HAL), which is documented in Chapter 7.