Linux Kernel Architecture

Chapter 14: Kernel Activities

Work in the entry and exit path of an interrupt is made even more difficult by the

fact that the processor may be in either user mode or kernel mode when an interrupt

arrives. This requires several additional technical modifications that, for reasons of

clarity, are not shown in Figure 14.2. (There is no need to switch between kernel

mode stack and user mode stack, and there is no need to check whether it is

necessary to call the scheduler or deliver signals.)

The terminterrupt handleris used ambiguously. It is used to designate invocation of an ISR call by

the CPU, and combines the entry/exit path and the ISR itself. Of course, it would be more correct

to refer only to the routine that is executedbetweenthe entry path and the exit path and that is

implemented in C.

Interrupt Handlers

Interrupt handlers can encounter difficulties particularly when further interrupts occur while they

are executing. Although this can be prevented by disabling interrupts during processing by a

handler, this creates other problems such as missing important interrupts.Masking(the term used

to denote the selective disabling of one or moreinterrupts) can therefore only be used for short

periods.

ISRs must therefore satisfy two requirements:

1. Implementation (above all, when other interrupts are disabled) must consist of as little code
   as possible to support rapid processing.


2. Interrupt handler routines that can be invoked during the processing of other ISRs must not
   interfere with each other.

Whereas the latter requirement can be satisfied by intelligent programming and clever ISR design, it

is rather more difficult to fulfill the former. Depending on the specific interrupt, a fixed programmust

be run to satisfy the minimum requirements for remedying the situation. Code size cannot therefore be

reduced arbitrarily.

How does the kernel resolve this dilemma? Not every part of an ISR is equally important. Generally, each

handler routine can be divided into three parts of differing significance:

1. Criticalactions must be executed immediately following an interrupt. Otherwise, system
   stability or correct operation of the computer cannot be maintained. Other interrupts must
   be disabled when such actions are performed.


2. Noncriticalactions should also be performed as quickly as possible but with enabled inter-
   rupts (they may therefore be interrupted by other system events).


3. Deferrableactions are not particularly important and need not be implemented in the inter-
   rupt handler. The kernel can delay these actions and perform them when it has nothing
   better to do.

The kernel makestaskletsavailable to perform deferrable actions at a later time. I deal with tasklets in

more detail in Section 14.3.