一、前言
Linux的中斷宏觀分為兩種：軟中斷和硬中斷。聲明一下，這裡的軟和硬的意思是指和軟件相關以及和硬件相關，而不是軟件實現的中斷或硬件實現的中斷。
軟中斷就是"信號機制"。軟中不是軟件中斷。Linux通過信號來產生對進程的各種中斷操作，我們現在知道的信號共有31個，其具體內容這裡略過，感興趣讀者可參看相關參考文獻[1]。一般來說，軟中斷是由內核機制的觸發事件引起的（例如進程運行超時），但是不可忽視有大量的軟中斷也是由於和硬件有關的中斷引起的，例如當打印機端口產生一個硬件中斷時，會通知和硬件相關的硬中斷，硬中斷就會產生一個軟中斷並送到操作系統內核裡，這樣內核就會根據這個軟中斷喚醒睡眠在打印機任務隊列中的處理進程。
硬中斷就是通常意義上的"中斷處理程序"，它是直接處理由硬件發過來的中斷信號的。當硬中斷收到它應當處理的中斷信號以後，就回去自己驅動的設備上去看看設備的狀態寄存器以了解發生了什麼事情，並進行相應的操作。對於軟中斷，我們不做討論，那是進程調度裡要考慮的事情。由於我們討論的是設備驅動程序的中斷問題，所以焦點集中在硬中斷裡。我們這裡討論的是硬中斷，即和硬件相關的中斷。
二、中斷產生
要中斷，是因為外設需要通知操作系統她那裡發生了一些事情，但是中斷的功能僅僅是一個設備報警燈，當燈亮的時候中斷處理程序只知道有事情發生了，但發生了什麼事情還要親自到設備那裡去看才行。也就是說，當中斷處理程序得知設備發生了一個中斷的時候，它並不知道設備發生了什麼事情，只有當它訪問了設備上的一些狀態寄存器以後，才能知道具體發生了什麼，要怎麼去處理。
設備通過中斷線向中斷控制器發送高電平告訴操作系統它產生了一個中斷，而操作系統會從中斷控制器的狀態位知道是哪條中斷線上產生了中斷。PC機上使用的中斷控制器是8259，這種控制器每一個可以管理8條中斷線，當兩個8259級聯的時候共可以控制15條中斷線。這裡的中斷線是實實在在的電路，他們通過硬件接口連接到CPU外的設備控制器上。
三、IRQ
並不是每個設備都可以向中斷線上發中斷信號的，只有對某一條確定的中斷線勇有了控制權，才可以向這條中斷線上發送信號。由於計算機的外部設備越來越多，所以15條中斷線已經不夠用了，中斷線是非常寶貴的資源。要使用中斷線，就得進行中斷線的申請，就是IRQ(Interrupt Requirement)，我們也常把申請一條中斷線成為申請一個IRQ或者是申請一個中斷號。
IRQ是非常寶貴的，所以我們建議只有當設備需要中斷的時候才申請占用一個IRQ，或者是在申請IRQ時采用共享中斷的方式，這樣可以讓更多的設備使用中斷。
無論對IRQ的使用方式是獨占還是共享，申請IRQ的過程都是一樣的，分為3步：
1．將所有的中斷線探測一遍，看看哪些中斷還沒有被占用。從這些還沒有被占用的中斷中選一個作為該設備的IRQ。
2．通過中斷申請函數申請選定的IRQ，這是要指定申請的方式是獨占還是共享。
3．根據中斷申請函數的返回值決定怎麼做：如果成功了萬事大吉，如果沒成功則或者重新申請或者放棄申請並返回錯誤。
申請IRQ的過程，在參考書的配的源代碼裡有詳細的描述，讀者可以通過仔細閱讀源代碼中的short一例對中斷號申請由深刻的理解。
四、中斷處理程序
Linux中的中斷處理程序很有特色，它的一個中斷處理程序分為兩個部分：上半部（tophalf）和下半部(bottom half)。之所以會有上半部和下半部之分，完全是考慮到中斷處理的效率。
上半部的功能是"登記中斷"。當一個中斷發生時，他就把設備驅動程序中中斷例程的下半部掛到該設備的下半部執行隊列中去，然後就沒事情了--等待新的中斷的到來。這樣一來，上半部執行的速度就會很快，他就可以接受更多她負責的設備產生的中斷了。上半部之所以要快，是因為它是完全屏蔽中斷的，如果她不執行完，其它的中斷就不能被及時的處理，只能等到這個中斷處理程序執行完畢以後。所以，要盡可能多得對設備產生的中斷進行服務和處理，中斷處理程序就一定要快。
但是，有些中斷事件的處理是比較復雜的，所以中斷處理程序必須多花一點時間才能夠把事情做完。可怎麼樣化解在短時間內完成復雜處理的矛盾呢，這時候Linux引入了下半部的概念。下半部和上半部最大的不同是下半部是可中斷的，而上半部是不可中斷的。
下半部幾乎做了中斷處理程序所有的事情，因為上半部只是將下半部排到了他們所負責的設備的中斷處理隊列中去，然後就什麼都不管了。下半部一般所負責的工作是察看設備以獲得產生中斷的事件信息，並根據這些信息（一般通過讀設備上的寄存器得來）進行相應的處理。如果有些時間下半部不知道怎麼去做，他就使用著名的鴕鳥算法來解決問題--說白了就是忽略這個事件。
由於下半部是可中斷的，所以在它運行期間，如果其它的設備產生了中斷，這個下半部可以暫時的中斷掉，等到那個設備的上半部運行完了，再回頭來運行它。但是有一點一定要注意，那就是如果一個設備中斷處理程序正在運行，無論她是運行上半部還是運行下半部，只要中斷處理程序還沒有處理完畢，在這期間設備產生的新的中斷都將被忽略掉。因為中斷處理程序是不可重入的，同一個中斷處理程序是不能並行的。
在Linux Kernel 2.0以前，中斷分為快中斷和慢中斷（偽中斷我們這裡不談），其中快中斷的下半部也是不可中斷的，這樣可以保證它執行的快一點。但是由於現在硬件水平不斷上升，快中斷和慢中斷的運行速度已經沒有什麼差別了，所以為了提高中斷例程事務處理的效率，從Linux kernel 2.0以後，中斷處理程序全部都是慢中斷的形式了--他們的下半部是可以被中斷的。
但是，在下半部中，你也可以進行中斷屏蔽--如果某一段代碼不能被中斷的話。你可以使用cti、sti或者是save_flag、restore_flag來實現你的想法。至於他們的用法和區別，請參看本文指定參考書中斷處理部分。
進一步的細節請讀者參看本文指定參考書，這裡就不再所說了，詳細介紹細節不是我的目的，我的目的是整理概念。
五、置中斷標志位
在處理中斷的時候，中斷控制器會屏蔽掉原先發送中斷的那個設備，直到她發送的上一個中斷被處理完了為止。因此如果發送中斷的那個設備載中斷處理期間又發送了一個中斷，那麼這個中斷就被永遠的丟失了。
之所以發生這種事情，是因為中斷控制器並不能緩沖中斷信息，所以當前一個中斷沒有處理完以前又有新的中斷到達，他肯定會丟掉新的中斷的。但是這種缺陷可以通過設置主處理器(CPU)上的"置中斷標志位"（sti）來解決，因為主處理器具有緩沖中斷的功能。如果使用了"置中斷標志位"，那麼在處理完中斷以後使用sti函數就可以使先前被屏蔽的中斷得到服務。
六、中斷處理程序的不可重入性
上一節中我們提到有時候需要屏蔽中斷，可是為什麼要將這個中斷屏蔽掉呢？這並不是因為技術上實現不了同一中斷例程的並行，而是出於管理上的考慮。之所以在中斷處理的過程中要屏蔽同一IRQ來的新中斷，是因為中斷處理程序是不可重入的，所以不能並行執行同一個中斷處理程序。在這裡我們舉一個例子，從這裡子例中可以看出如果一個中斷處理程序是可以並行的話，那麼很有可能會發生驅動程序鎖死的情況。當驅動程序鎖死的時候，你的操作系統並不一定會崩潰，但是鎖死的驅動程序所支持的那個設備是不能再使用了--設備驅動程序死了，設備也就死了。
其中激發PS1的事件會使A1產生一個中斷，然後B1去讀R1中已有的數據，然後代碼C1向R2中寫數據。而激發PS2的事件會使A2產生一個中斷，然後B2刪除R1中的數據，然後C2讀去R2中的數據。
如果PS1先產生，且當他執行到A1和B1之間的時候，如果PS2產生了，這是A2會產生一個中斷，將PS2中斷掉（掛到任務隊列的尾部），然後刪除了R1的內容。當PS2運行到C2時，由於C1還沒有向R2中寫數據，所以C2將會在這裡被掛起，PS2就睡眠在代碼C2上，直到有數據可讀的時候被信號喚醒。這是由於PS1中的B2原先要讀的R1中的數據被PS2中的B2刪除了，所以PS1頁會睡眠在B1上，直到有數據可讀的時候被信號喚醒。這樣一來，喚醒PS1和PS2的事件就永遠不會發生了，因此PS1和PS2之間就鎖死了。
由於設備驅動程序要和設備的寄存器打交道，所以很難寫出可以重入的代碼來，因為設備寄存器就是全局變量。因此，最簡潔的辦法就是禁止同一設備的中斷處理程序並行，即設備的中斷處理程序是不可重入的。
有一點一定要清楚：在2.0版本以後的Linux kernel中，所有的上半部都是不可中斷的（上半部的操作是原子性的）；不同設備的下半部可以互相中斷，但一個特定的下半部不能被它自己所中斷（即同一個下半部不能並行）。
由於中斷處理程序要求不可重入，所以程序員也不必為編寫可重入的代碼而頭痛了。以我的經驗，編寫可重入的設備驅動程序是可以的，編寫可重入的中斷處理程序是非常難得，幾乎不可能。
七、避免競爭條件的出現
我們都知道，一旦競爭條件出現了，就有可能會發生死鎖的情況，嚴重時可能會將整個系統鎖死。所以一定要避免競爭條件的出現。這裡我不多說，大家只要注意一點：絕大多數由於中斷產生的競爭條件，都是在帶有中斷的內核進程被睡眠造成的。所以在實現中斷的時候，一定要相信謹慎的讓進程睡眠，必要的時候可以使用cli、sti或者save_flag、restore_flag。具體細節請參看本文指定參考書。
八、實現
如何實現驅動程序的中斷例程，是各位讀者的事情了。只要你們仔細的閱讀short例程的源代碼，搞清楚編寫驅動程序中斷例程的規則，就可以編寫自己的中斷例程了。只要概念正確，在正確的規則下編寫你的代碼，那就是符合道理的東西。我始終強調，概念是第一位的，能編多少代碼是很其次的，我們一定要概念正確，才能進行正確的思考。
