ULK --- Chap 4: Interrupts and Exceptions

An interrupt is usually defined as an event that alters the sequence of instructions executed by a

processor. Such events correspond to electrical signals generated by hardware circuits both inside

and outside chip.

Interrupts are often divided into synchronous and asynchronous intertupts:

Synchronous interrupts are produced by the CPU control unit while executing instructions and are

called synchronous because the control unit issues them only after terminating the execution of an

instruction. 

Asynchronous interrupts are generated by other hardware devices at arbitrary times with respect to

the CPU clock signals.

Intel microprocessor manuals designate synchronous and asynchronous interrupts as exceptions and

interrupts, respectively. We will adopt this classification, although we will occasionally use the term

"interrupt signal" to designate both types of together.

Interrupts are issued by interval timers and I/O devices; for instance, the arrival of a keystroke from 

a user sets off an interrupt.

Exceptions, on the other hand, are caused either by programming errors or by anomalous conditions

that must be handled by the kernel. In the first case, the kernel handles the exception by delivering

to the current process one of the signals familiar to every UNIX programmer. In the second case, the

kernel performs all the steps needed to recover from the anomalous condition, such as page fault or

a request --- via an assembly language instruction such as int or sysenter --- for a kernel service.

We start by describing in the next section the motivation for introducing such signals. We then show

how the well-known IRQs (Interrupt ReQusts) issued by I/O devices give rise to interrupts, and we 

detail how 80x86 processors handle interrupts and exceptions at the hardware level. Then we illustrate

, in the section "Initializing the Interrupt Descriptor Table", how Linux initializes all the data structures

required by the 80x86 interrupt architecture. The remaining three sections describe how Linux handles

interrupt signals at the software level.

One word of caution before moving on: in this chapter, we cover only "classic" interrupts common to

all PCs; we do not cover the nonstandard interrupts of some architectures.

　　　　　　　　　　　　　　　　　　　　The Role of Interrupt Signals

As the name suggests, interrupt signals provide a way to divert the processor to code outside the normal

flow of control. When an interrupt signal arrives, the CPU must stop what it is currently doing and switch

to a new activity; it does this by saving the current value of the program counter (i.e., the content of the

eip and cs registers) in the Kernel Mode stack and by placing an address related to the interrupt type into

the program counter.

There are some things in this chapter that will remind you of the context switch described in the previous

chapter, carried out when a kernel substitutes one process for another. But there is a key difference between

interrupt handling and process switching: the code executed by an interrupt or by an exception handlers

is not a process. Rather, it is a kernel control path that runs at the expense of the same process that was

running when the interrupt occurred. As a kernel control path, the interrupt handler is lighter then a process

(it has less context and requires less time to set up or tear down).

Interrupt handling is one of the most sensitive tasks performed by the kernel, because it must satisfy the

following constraints:

Interrupts can come anytime, when the kernel may want to finish something else it was trying to do. The 

kernel's goal is therefore to get the interrupt out of the way as soon as possible and defer as much processing

as it can. For instance, suppose a block of data has arrived on a network line. When the hardware interrupts

the kernel, it could simple mark the presence of data, give the processor back to whatever was running before,

and do the rest of the processing later (such as moving the data into a buffer where its recipient process can

find it, and then restarting the process). The activities that the kernel needs to perform in response to an

interrupt are thus divided into a critical urgent part that the kernel executes right away and a deferrable part

that is left for later. as

Because interrupts can come anytime, the kernel might be handling one of them while another one (of a

different type) occurs. This should be allowed as much as possible, because it keeps the I/O devices busy.

As a result, the interrupt handlers must be coded so that the corresponding kernel control paths can be executed

in a nested manner. When the last kernel control path terminates, the kernel must be able to resume execution

of the interrupted process or switch to another process if the interrupt signal has caused a rescheduling activity.

Although the kernel may accept a new interrupt signal while handling a previous one, some critical regions exist

inside the kernel code where interrupt must be disabled. Such critical regions must be limited as much as

possible because, according to the previous requirement, the kernel, and particularly the interrupt handlers, 

should run most of the time with the interrupts enabled.