Chapter 14: Kernel Activities
routine(ISRforshort)oraninterrupt handler. The purpose of this routine is to handle exception conditions
or anomalous situations — after all, the specific goal of an interrupt is to draw the attention of the kernel
to such changes.A simple distinction between synchronous and asynchronous interrupts is not sufficient to fully describe
the features of these two types of interrupt. A further aspect needs to be considered. Many interrupts can
be disabled, but a few cannot. The latter category includes, for example, interrupts issued as a result of
hardware faults or other system-critical events.Wherever possible, the kernel tries to avoid disabling interrupts because they are obviously detrimental
to system performance. However, there are occasions when it isessentialto disable them to prevent the
kernel itself from getting into serious trouble. As you will see when we take a closer look at interrupt
handlers, major problems may arise in the kernel if a second interrupt occurswhilea first interrupt is
being handled. If the kernel is interrupted while processing what is already critical code, the synchro-
nization problems discussed in Chapter 5 may arise. Inthe worst case scenario, this can provoke a kernel
deadlock that renders the entire system unusable.If the kernel allows itself too much time to process an ISR when interrupts are disabled, it can (and
will) happen that interrupts are lost although they are essential for correct system operation. The kernel
resolves this problem by enabling interrupt handlers to be divided into two parts — a performance-
criticaltop halfthat executes with disabled interrupts, and a less importantbottom halfused later to
perform all less important actions. Earlier kernel versions included a mechanism of the same name
for deferring activities to a later time. However, this has been replaced by more efficient mechanisms,
discussed below.Each interrupt has a number. If interrupt numbernis assigned to a network card andm=nis assigned to
the SCSI controller, the kernel is able to differentiate between the two devices and call the corresponding
ISR to perform a device-specific action. Of course, the same principle also applies for exceptions where
different numbers designate different exceptions. Unfortunately, owing to specific (and usually histori-
cal) design ‘‘features‘‘(the IA-32 architecture is a particular case in point), the situation is not always as
simple as just described. Because only very few numbers are available for hardware interrupts, they must
be shared by several devices. On IA-32 processors, the maximum number is usually 15, not a particularly
generous figure — especially considering that some interrupts are already permanently assigned to stan-
dard system components (keyboard, timers, etc.), thus restricting still further the number available for
other peripheral devices.This procedure is known asinterrupt sharing.^2 However, both hardware support and kernel support
are needed to use this technique because it is necessary to identify the device from which an interrupt
originates. This is covered in greater detail in this chapter.14.1.2 Hardware IRQs
The terminterrupthas been used carelessly in the past to denote interrupts issued by the CPU as well as
by external hardware. Savvy readers will certainly have noticed that this is not quite correct. Interrupts
cannot be raised directly by processor-external peripherals but must be requested with the help of a
standard component known as aninterrupt controllerthat is present in every system.(^2) Naturally, bus systems with a sophisticatedoverall designare able to dispense with this option. They provide so many interrupts for
hardware devices that there is no need for sharing.