Linux Kernel Architecture

Chapter 14: Kernel Activities

} while (action);

...

return retval;

}

ImplementingHandlerRoutines

Some important points must be noted when implementing handler routines. These greatly influence not

only the speed but also the stability of the system.

Restrictions

The main problem when implementing ISRs is that they execute in what is known as theinterrupt context.

Kernel code can sometimes run both in the regular context and in the interrupt context. To distinguish

between these two variants and to design code accordingly, the kernel provides thein_interruptfunc-

tion to indicate whether or not an interrupt is currently being serviced.

The interrupt context differs in three important points from the normal context in which the kernel

otherwise executes:

1. Interrupts are executed asynchronously; in other words, they can occur at any time. As a
   result, the handler routine is not executed in aclearly defined environment with respect to
   the reservation of userspace. This prohibits access to userspace and prevents above all the
   copying of memory contents into and out of the userspace addresses.
   For network drivers, for example, it is therefore not possible to forward data received
   directly to the waiting application. After all, it is not certain that the application waiting for
   the data is running at the time (this is, in fact, extremely unlikely).


2. The scheduler may not be invoked in the interrupt context. It is therefore impossible to sur-
   render control voluntarily.


3. The handler routine may not go to sleep. Sleep states can only be broken when an external
   event causes a state change and wakes the process. However, because interrupts are not
   allowed in the interrupt context, the sleeping process would wait forever for the relieving
   news. As the scheduler may also not be invoked, no other process can be selected to replace
   the current sleeping process.
   It is not, of course, enough simply to make sure that only the direct code of a handler routine
   is free of possible sleeping instructions. All invoked procedures and functions (and proce-
   dures and functions invoked by these, in turn)mustbefreeofexpressionsthatcouldgoto
   sleep. Checking that this is the case is not always trivial and must be done very carefully,
   particularly if control paths have numerous branches.

Implementing Handlers

Recall that the prototype of ISR functions is specified byirq_handler_t. I have not shown the actual

definition of this typedef, but do so now:

<interrupt.h>

typedef irqreturn_t (*irq_handler_t)(int, void *);

irqspecifies the IRQ number, anddev_idis the device ID passed when the handler is registered.

irqreturn_tis anothertypedefto a simple integer.