Linux Device Drivers

Bottom Halves

One of the main problems with interrupt handling is how to perform longish tasks within a handler. Linux resolves this problem by splitting the interrupt handler into two halves: the so-called ``top half'' is the routine you register through request_irq, and the ``bottom half'' (``bh'' for short) is a routine that is scheduled by the top half, to be executed later, at a safer time.

But what is a bottom half useful for?

The big difference between the top-half handler and the bottom half is that all interrupts are enabled during execution of the bh—that’s why it runs at a ``safer'' time. In the typical scenario, the top half saves device data to a device-specific buffer, marks its bottom half, and exits: this is very fast. The bh then dispatches newly arrived data to the processes, awakening them if necessary. This setup permits the top half to service a new interrupt while the bottom half is still working. New data arriving before the top half terminates, on the other hand, are lost because the IRQ line is disabled in the interrupt controller.

Every serious interrupt handler is split this way. For instance, when a network interface reports the arrival of a new packet, the handler just retrieves the data and pushes it up to the protocol layer; actual processing of the packet is performed in a bottom half.

This kind of job should be reminiscent of task queues; actually, task queues have evolved from an older implementation of bottom halves. Even version 1.0 of the kernel ...