Linux Kernel Architecture

Chapter 14: Kernel Activities

From the peripheral devices (or their slots) electronic lines lead to the component used to send interrupt

requests to the interrupt controller. After performing various electro-technical tasks, which are of no fur-

ther interest to us here, the controller forwards such requests to the interrupt inputs of the CPU. Because

peripheral devices cannot directly force interrupts but must request them via the above component, such

requests are known more correctly as IRQs, orinterrupt requests.

Because, in terms of software, the difference between IRQs and interrupts is not all that great, the two

terms are often used interchangeably. This is not a problem as long as it is clear what is meant.

However, one important point concerning the numbering of IRQs and interrupts should not be over-

looked as it has an impact on software. Most CPUs make only a small extract from the whole range of

available interrupt numbers available for processing hardware interrupts. This range is usually in the

middle of the number sequence; for example, IA-32 CPUs provide a total of 16 numbers from 32 to 47.

As any reader who has configured an I/O card on an IA-32 system or has studied the contents of

/proc/interruptsknows, IRQ numbering of expansion cards starts at 0 and finishes at 15, provided the

classical interrupt controller 8256A is used. This means that there are also 16 different options but with

different numerical values. As well as being responsible for the electrical handling of the IRQ signals,

the interrupt controller also performs a ‘‘conversion‘‘ between IRQ number and interrupt number; with

the IA-32 system, this is the equivalent of simply adding 32. If a device issues IRQ 9, the CPU produces

interrupt 41; this must be taken into account when installing interrupt handlers. Other architectures use

other mappings between interrupt and IRQ numbers, but I will not deal with these in detail.

14.1.3 Processing Interrupts

Once the CPU has been informed of an interrupt, it delegates further handling to a software routine

that corrects the fault, provides special handling, or informs a user process of an external event. Because

each interrupt and each exception has a unique number, the kernel uses an array containing pointers to

handler functions. The associated interrupt number is found by referring to the array position, as shown

in Figure 14-1.

handle_page_fault

handle_whatever

n n+1 n+2 n+3 n+4 n+5 n+6 n+7

Figure 14-1: Managing interrupt handlers.

Entry andExit Tasks

As Figure 14-2 shows, interrupt handling is divided into three parts. First, a suitable environment in

which the handler function can execute must be set up; then the handler itself is called, and finally the

system is restored (in the view of the current program) to its exact statepriorto the interrupt. The parts

that precede and follow invocation of the interrupt handler are known as theentryandexit path.

The entry and exit tasks are also responsible for ensuring that the processor switches from user mode to

kernel mode. A key task of the entry path is to make the switch from the user mode stack to the kernel