Linux Kernel : Interrupts Basics

What is an Interrupt?

Any hardware which wants to intimate the CPU about anything be it data or any other thing uses electrical signals to do so.These are called interrupts.The processor receives the interrupt and signals the operating system to enable the operating system to respond to the new data. Hardware devices generate interrupts asynchronously with respect to the processor clock—they can occur at any time. Consequently, the kernel can be interrupted at any time to process interrupts.Upon receiving an interrupt, the interrupt controller sends a signal to the processor.The processor detects this signal and interrupts its current execution to handle the interrupt.The processor can then notify the operating system that an interrupt has occurred, and the operating system can handle the interrupt propriately.Different devices can be associated with different interrupts by means of a unique value associated with each interrupt. This is often called as IRQ lines.


Interrupt Handler

An interrupt handler is a routine/function which takes the action. Example, when an USB is connected,the USB interrupt handler should be called.Each device that generates interrupts has an associated interrupt handler. For example, one function handles interrupts from the system timer,whereas another function handles interrupts generated by the keyboard.The interrupt handler for a device is part of the device’s driver.

What differentiates interrupt handlers from other kernel functions is that the kernel invokes them in response to interrupts and that they run in a special context (discussed later in this chapter) called interrupt context.This special context is occasionally called atomic context because, as we shall see, code executing in this context is unable to block.Because an interrupt can occur at any time, an interrupt handler can, in turn, be executed at any time. It is imperative that the handler runs quickly, to resume execution of the interrupted code as soon as possible.Therefore, while it is important to the hardware that the operating system services the interrupt without delay, it is also important to the rest of the system that the interrupt handler executes in as short a period as possible.It is upto programmer to write the interrupt handler in such a way that long delay can be avoided.

Often, however, interrupt handlers have a large amount of work to perform. For example, consider the interrupt handler for a network device. On top of responding to the hardware, the interrupt handler needs to copy networking packets from the hardware into memory, process them, and push the packets down to the appropriate protocol stack or application. Obviously, this can be a lot of work, especially with today’s gigabit and 10-gigabit Ethernet cards.

Interrupt Processing : Top Halves and Bottom Halves

The processing of interrupts is split into two parts, top halves and bottom halves. This is done in order to achieve the goal of fast interrupt handling also capable of doing a larger work.

In RTOS like Qualcomm's REX, the keypad interrupt handler sends a signal to a keypad thread, and from thereon the thread takes care of all other things. We can say that the handler is a top-halve and the thread execution is a bottom-halve. Bottom-Halves can loop around and do the task based on need  whereas top-halves need to execute as soon as possible. Note that Linux does the bottom-halves in quite different ways. Linux contains a proper framework to deal with bottom-halves.

In other words,The top half is run immediately upon receipt of the interrupt and performs only the work that is time-critical, such as acknowledging receipt of the interrupt or resetting the hardware.Work that can be performed later is deferred until the bottom half.The bottom half runs in the future, at a more convenient time, with all interrupts enabled.

In a typical network card device driver, the interrupt handler is to required to quickly copy the data from network card(usually because of limited size of the network card buffer) and put it into the main memory and rest of the thing can be done in a bottom-halve. Thus this prevent loss of data from network card buffer.