Linux Device Drivers

Implementing a Handler

So far, we’ve learned to register an interrupt handler, but not to write one. Actually, there’s nothing unusual about a handler--it’s ordinary C code.

The only peculiarity is that a handler runs at interrupt time and therefore suffers some restrictions on what it can do. These restrictions are the same as those we saw with task queues. A handler can’t transfer data to or from user space, because it doesn’t execute in the context of a process. A fast handler, however, can count on being executed atomically and doesn’t need to protect itself against race conditions when accessing shared data items. Slow handlers are not atomic in that other interrupts can be serviced while the slow handler is running.

The role of an interrupt handler is to give feedback to its device about interrupt reception and to read or write data according to the meaning of the interrupt being serviced. The first step usually consists of clearing a bit on the interface board; most hardware devices won’t generate other interrupts until their ``interrupt-pending'' bit has been cleared. Some devices don’t require this step because they don’t have an ``interrupt-pending'' bit; such devices are a minority, although the parallel port is one of them. For that reason, short does not have to clear such a bit.

A typical task for an interrupt handler is awakening processes sleeping on the device if the interrupt signals the event they’re waiting for, such as the arrival of new data.

To stick with the ...