Top Half & Bottom Half

    Linux 将完整的 interrupt handler 切成2个部份（half）：top half 与 bottom half。Top half 是在呼叫 request_irq() 时所指定的 interrupt handler 函数，bottom half 则是由 top half 所排程（scheduling），真正负责响应中断的 task。
    一般来说，top half 的基本实作原则如下：
    1. 储存装置相关数据，这个部份会涉及「中断不同步」的议题，在这里先不做解释。
    2. 将 bottom half 排程后结束执行。
    Top half 是真正接受中断请求的 task，因此应避免执行过久。由 top half 的实作原则可以看出，top half 真正要做的工作其实只有排程 bottom half，因此执行的速度将会非常快。Top half 与 bottom half 的最大差别为，bottom half 在执行时，interrupt 是开启的，因此 CPU 仍然可以接受中断请求。

    由此也可以看出另外一个 bottom half 机制的特点：当 bottom half 尚未结束执行时，top half 仍然可以处理中断请求。另外，bottom half 就是 interrupt handler，因此「也视为」在 interrupt mode 下执行。
=============================================================
    以下摘自《Linux设备驱动开发详解》
    设备的中断会打断内核中进程的正常调度和运行，系统对更高吞吐率的追求势必要求中断服务程序尽可能的短小精悍。但是这个良好的愿望往往与现实并不吻合。在大多数真实的系统中，当中断到来时，要完成的工作往往并不会是短小的，它可能进行较大量的耗时处理。
为了在中断执行时间尽可能短和中断处理需完成大量工作之间找到一个平衡点，Linux将中断处理程序分解为两个部分：顶半部和底半部（top half和bottom half）。

    顶半部完成尽可能少的比较紧急的功能，它往往只是简单的读取寄存器中中断状态并清除中断标志后就进行“登记中断”的工作。“登记中断”意味着将底半部处理程序挂到该设备的底半部执行队列中去。这样，顶半部执行的速度就会很快，可以服务更多的中断请求。
    现在，中断处理工作的中心就落在了底半部的头上，它来完成中断事件的绝大多数认为。底半部几乎做了中断处理程序所有的事情，而其可以被新的中断打断，这也是底半部和顶半部最大的不同，因为顶半部往往被设计成不可中断。底半部则相对来说并不是非常紧急的，而且相对比较耗时，不在硬件中断服务程序中执行。
    尽管顶半部、底半部的结合能够改善系统的相应能力，但是，僵化地认为Linux设备驱动中的中断处理一定要分为两个半部则是不对的。如果中断要处理的工作本身很少，则完全可以直接在顶半部全部完成。