中斷上下部分

參考：http://blog.csdn.net/tiangwan2011/article/details/7254752    

從 linux1.x版本開始，中斷處理常式從概念上被分為上半部分（top half）和下半部分（bottom half）。在中斷髮生時上半部分的處理 過程立即執行，因為它是完全屏蔽中斷的，所以要快，否則其它的中斷就得不到及時的處理。但是下半部分（如果有的話）幾乎做了中斷處理常式所有的事情，可以
延遲執行。核心把上半部分和下半部分作為獨立的函數來處理，上半部分的功能就是“登記中斷”，決定其相關的下半部分是否需要執行。需要立即執行的部分必須 位於上半部分，而可以延遲的部分可能屬於下半部分。下半部分的任務就是執行與中斷處理密切相關但上半部分本身不執行的工作，如查看裝置以獲得產生中斷的時 間資訊，並根據這些資訊（一般通過讀裝置上的寄存器得來）進行相應的處理。從這裡我們可以看出下半部分其實是上半部分引起的，例如當印表機連接埠產生一個中 斷時，其中斷處理常式會立即執行相關的上半部分，上半部分就會產生一個非強制中斷（下半部分的一種）並送到作業系統核心裡，這樣核心就會根據這個非強制中斷喚醒睡
眠的印表機任務隊列中的處理進程。

                                      中斷上下部分分解

為什麼要將一個中斷分為如此兩部分？下面的幾個經典原因可以很好的詮釋這個問題。

1.中斷可以隨時的打斷處理機對其他程式的執行，如果被打斷的代碼對系統很重要，那麼此時中斷處理常式的執行時間應該是越短越好。

2.通過上文我們知道，中斷處理常式正在執行時，會屏蔽同條中斷線上的插斷要求；而更嚴重的是，如果設定了IRQF_DISABLED，那麼該中斷服務程式執行是會屏蔽所有其他的插斷要求。那麼此時應該讓中斷處理常式執行的越快越好。

        上面的幾個例子都要求中斷服務程式的執行時間越短越好。一般的，中斷處理常式會在上半部分執行。而事實上，幾乎所有的情況，上半部分就只執行中斷處理常式。因此，我們可以這樣認為：一個完整的中斷處理流程是由中斷處理常式和下半部分共同完成的。

        這樣劃分是有一定原因的，因為我們必須有一個快速、非同步而且簡單的處理常式專門來負責對硬體的插斷要求做出快速響應，與此同時也要完成那些對時間要求很嚴格的操作。而那些對時間要求相對寬鬆，其他的剩餘工作則會在稍候的任意時間執行，也就是在所謂的下半部分去執行。

        總之，這樣劃分一個中斷處理過程主要是希望減少中斷處理常式的工作量（當然了，理想情況是將全部工作都拋給下半段。但是中斷處理常式至少應該完成對插斷要求的相應。），因為在它運行期間至少會使得同級的插斷要求被屏蔽，這些都直接關係到整個系統的響應能力和效能。而在下半段執行期間，則會允許響應所有的中斷。和上半段只能通過中斷處理常式實現不同的是，下半部可以通過多種機制來完成：小任務（tasklet），工作隊列，非強制中斷。

        中斷上下兩部分最大的不同是上半部分不可中斷，而下半部分可中斷。在理想的情況下，最好是中斷處 理程式上半部分將所有工作都交給下半部分執行，這樣的話在中斷處理常式上半部分中完成的工作就很少，也就能儘可能快地返回。但是，中斷處理常式上半部分一 定要完成一些工作，例如，通過操作硬體對中斷的到達進行確認，還有一些從硬體拷貝資料等對時間比較敏感的工作。剩下的其他工作都可由下半部分執行。

 對於上半部分和下半部分之間的劃分沒有嚴格的規則，靠驅動程式開發人員自己的編程習慣來劃分，但是還是有一些習慣供參考：

Ⅰ．如果該任務對時間比較敏感，將其放在上半部中執行。

Ⅱ．如果該任務和硬體相關，一般放在上半部中執行。

Ⅲ．如果該任務要保證不被其他中斷打斷，放在上半部中執行（因為這是系統關中斷）。

Ⅳ．其他不太緊急的任務，般考慮在下半部執行。

       下半部分並不需要指明一個確切時間，只要把這些任務延遲一點，讓它們在系統不太忙併且中斷恢複後執行就可以了。通常下半部分在中斷處理常式一返回就會馬上運 行，下半部分執行的關鍵在於當它們啟動並執行時候，允許響應所有的中斷。下半部分是一種推後執行任務，它將某些不那麼緊迫的任務延遲到系統更方便的時刻運行。 核心中實現下半部的手段不斷演化，目前已經從最原始的BH（bottom half）衍生出BH（在2.5中去除）、非強制中斷（softirq在2.3引 入）、tasklet（在2.3引入）、工作隊列（work queue在2.5引入）。這裡主要分析討論後三種方式。