Linux Device Drivers, Second Edition

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. Handlers also cannot do anything that would sleep, such as calling sleep_on, allocating memory with anything other than GFP_ATOMIC, or locking a semaphore. Finally, handlers cannot call schedule.

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 frame grabber example, a process could acquire a sequence ...