轉自：http://www.cnblogs.com/hanyan225/archive/2011/07/17/2108609.html
中斷還是中斷，我講了很多次的中斷了，今天還是要講中斷，為啥呢？因為在作業系統中，中斷是必須要講的..
那麼什麼叫中斷呢， 中斷還是打斷，這樣一說你就不明白了。唉，中斷還真是有點像打斷。我們知道linux管理所有的硬體裝置，要做的第一件事先是通訊。然後，我們天天在說一句話：處理器的速度跟外圍硬體裝置的速度往往不在一個數量級上，甚至幾個數量級的差別，這時咋辦，你總不能讓處理器在那裡傻等著你硬體做好了告訴我一聲吧。這很容易就和日常生活聯絡起來了，這樣效率太低，不如我處理器做別的事情，你硬體裝置準備好了，告訴我一聲就得了。這個告訴，我們們說的輕鬆，做起來還是挺費勁啊！怎麼著，簡單一點，輪訓(polling)可能就是一種解決方法，缺點是作業系統要做太多的無用功，在那裡傻傻的做著不重要而要重複的工作，這裡有更好的辦法---中斷，這個中斷不要緊，關鍵在於從硬體裝置的角度上看，已經實現了從被動為主動的歷史性突破。
中斷的例子我就不說了，這個很顯然啊。分析中斷，本質上是一種特殊的電訊號，由硬體裝置發向處理器，處理器接收到中斷後，會馬上向作業系統反應此訊號的帶來，然後就由OS負責處理這些新到來的資料，中斷可以隨時發生，才不用操心與處理器的時間同步問題。不同的裝置對應的中斷不同，他們之間的不同從作業系統級來看，差別就在於一個數字標識-----中斷號。專業一點就叫中斷請求(IRQ)線,通常IRQ都是一些數值量。有些體系結構上，中斷好是固定的，有的是動態分配的，這不是問題所在，問題在於特定的中斷總是與特定的裝置相關聯，並且核心要知道這些資訊，這才是最關鍵的,不是麼？哈哈.
用書上一句話說：討論中斷就不得不提及異常，異常和中斷不一樣，它在產生時必須要考慮與處理器的時鐘同步，實際上，異常也常常稱為同步中斷，在處理器執行到由於程式設計失誤而導致的錯誤指令的時候，或者是在執行期間出現特殊情況，必須要靠核心來處理的時候，處理器就會產生一個異常。因為許多處理器體系結構處理異常以及處理中斷的方式類似，因此，核心對它們的處理也很類似。這裡的討論，大部分都是適合異常，這時可以看成是處理器本身產生的中斷。
中斷產生告訴中斷控制器，繼續告訴作業系統核心，核心總是要處理的，是不？這裡核心會執行一個叫做中斷處理程式或中斷處理例程的函式。這裡特別要說明，中斷處理程式是和特定中斷相關聯的，而不是和裝置相關聯，如果一個裝置可以產生很多中斷，這時該裝置的驅動程式也就需要準備多個這樣的函式。一箇中斷處理程式是裝置驅動程式的一部分，這個我們在linux裝置驅動中已經說過，就不說了，後面我也會提到一些。前邊說過一個問題：中斷是可能隨時發生的，因此必須要保證中斷處理程式也能隨時執行，中斷處理程式也要儘可能的快速執行，只有這樣才能保證儘可能快地恢復中斷程式碼的執行。
但是，不想說但是，大學第一節逃課的情形現在仍記憶猶新：又想馬兒跑，又想馬兒不吃草，怎麼可能！但現實問題或者不像想象那樣悲觀，我們的中斷說不定還真有奇蹟發生。這個奇蹟就是將中斷處理切為兩個部分或兩半。中斷處理程式上半部(top half)---接收到一箇中斷，它就立即開始開始執行，但只做嚴格時限的工作，這些工作都是在所有中斷被禁止的情況下完成的。同時，能夠被允許稍後完成的工作推遲到下半部(bottom half)去，此後，下半部會被執行，通常情況下，下半部都會在中斷處理程式返回時立即執行。我會在後面談論linux所提供的是實現下半部的各種機制。
說了那麼多，現在開始第一個問題：如何註冊一箇中斷處理程式。我們在linux驅動程式理論裡講過，通過一下函式可註冊一箇中斷處理程式：
|
1
|
int request_irq(unsigned int irq,irqreturn_t (*handler)(int, void *,struct pt_regs *),unsigned long irqflags,const char * devname,void *dev_id) |
有關這個中斷的一些引數說明，我就不說了，一旦註冊了一箇中斷處理程式，就肯定會有釋放中斷處理，這是呼叫下列函式：
|
1
|
void free_irq(unsigned int irq, void *dev_id) |
這裡需要說明的就是要必須要從程式上下文呼叫free_irq().好了，現在給出一個例子來說明這個過程,首先宣告一箇中斷處理程式：
|
1
|
static irqreturn_t intr_handler(int irq, void *dev_id, struct pt_regs *regs) |
注意：這裡的型別和前邊說到的request_irq()所要求的引數型別是匹配的，引數不說了。對於返回值，中斷處理程式的返回值是一個特殊型別，irqrequest_t,可能返回兩個特殊的值：IRQ_NONE和IRQ_HANDLED.當中斷處理程式檢測到一箇中斷時，但該中斷對應的裝置並不是在註冊處理函式期間指定的產生源時，返回IRQ_NONE;當中斷處理程式被正確呼叫，且確實是它所對應的裝置產生了中斷時，返回IRQ_HANDLED.C此外，也可以使用巨集IRQ_RETVAL(x)，如果x非0值，那麼該巨集返回IRQ_HANDLED,否則，返回IRQ_NONE.利用這個特殊的值，核心可以知道裝置發出的是否是一種虛假的(未請求)中斷。如果給定中斷線上所有中斷處理程式返回的都是IRQ_NONE，那麼，核心就可以檢測到出了問題。最後，需要說明的就是那個static了，中斷處理程式通常會標記為static，因為它從來不會被別的檔案中的程式碼直接呼叫。另外，中斷處理程式是無需重入的，當一個給定的中斷處理程式正在執行時，相應的中斷線在所有處理器上都會被遮蔽掉，以防止在同一個中斷上接收另外一個新的中斷。通常情況下，所有其他的中斷都是開啟的，所以這些不同中斷線上的其他中斷都能被處理，但當前中斷總是被禁止的。由此可見，同一個中斷處理程式絕對不會被同時呼叫以處理巢狀的中斷。
下面要說到的一個問題是和共享的中斷處理程式相關的。共享和非共享在註冊和執行方式上比較相似的。差異主要有以下幾點：
| 1.request_irq()的引數flags必須設定為SA_SHIRQ標誌。 2.對每個註冊的中斷處理來說，dev_id引數必須唯一。指向任一裝置結構的指標就可以滿足這一要求。通常會選擇裝置結構，因為它是唯一的，而且中 斷處理程式可能會用到它，不能給共享的處理程式傳遞NULL值。 3.中斷處理程式必須能夠區分它的裝置是否真的產生了中斷。這既需要硬體的支援，也需要處理程式有相關的處理邏輯。如果硬體不支援這一功能，那中 斷處理程式肯定會束手無策，它根本沒法知道到底是否與它對應的裝置發生了中斷，還是共享這條中斷線的其他裝置發出了中斷。 |
在指定SA_SHIRQ標誌以呼叫request_irq()時，只有在以下兩種情況下才能成功：中斷當前未被註冊或者在該線上的所有已註冊處理程式都指定了SA_SHIRQ.A。注意，在這一點上2.6與以前的核心是不同的，共享的處理程式可以混用SA_INTERRUPT. 一旦核心接收到一箇中斷後，它將依次呼叫在該中斷線上註冊的每一個處理程式。因此一個處理程式必須知道它是否應該為這個中斷負責。如果與它相關的裝置並沒有產生中斷，那麼中斷處理程式應該立即退出，這需要硬體裝置提供狀態暫存器(或類似機制)，以便中斷處理程式進行檢查。毫無疑問，大多數裝置都提這種功能。
當執行一箇中斷處理程式或下半部時，核心處於中斷上下文(interrupt context)中。對比程式上下文，程式上下文是一種核心所處的操作模式，此時核心代表程式執行，可以通過current巨集關聯當前程式。此外，因為程式是程式上下文的形式連線到核心中，因此，在程式上下文可以隨時休眠，也可以排程程式。但中斷上下文卻完全不是這樣，它可以休眠，因為我們不能從中斷上下文中呼叫函式。如果一個函式睡眠，就不能在中斷處理程式中使用它，這也是對什麼樣的函式能在中斷處理程式中使用的限制。還需要說明一點的是，中斷處理程式沒有自己的棧，相反，它共享被中斷程式的核心棧，如果沒有正在執行的程式，它就使用idle程式的棧。因為中斷程式共享別人的堆疊，所以它們在棧中獲取空間時必須非常節省。核心棧在32位體系結構上是8KB，在64位體系結構上是16KB.執行的程式上下文和產生的所有中斷都共享核心棧。
下面給出中斷從硬體到核心的路由過程(截圖選自liuux核心分析與設計p61)，然後做出總結：
圖一 中斷從硬體到核心的路由
上面的圖內部說明已經很明確了，我這裡就不在詳談。在核心中，中斷的旅程開始於預定義入口點，這類似於系統呼叫。對於每條中斷線，處理器都會跳到對應的一個唯一的位置。這樣，核心就可以知道所接收中斷的IRQ號了。初始入口點只是在棧中儲存這個號，並存放當前暫存器的值(這些值屬於被中斷的任務)；然後，核心呼叫函式do_IRQ().從這裡開始，大多數中斷處理程式碼是用C寫的。do_IRQ()的宣告如下：
|
1
|
unsigned int do_IRQ(struct pt_regs regs) |
因為C的呼叫慣例是要把函式引數放在棧的頂部，因此pt_regs結構包含原始暫存器的值，這些值是以前在彙編入口例程中儲存在棧上的。中斷的值也會得以儲存，所以，do_IRQ()可以將它提取出來，X86的程式碼為：
|
1
|
int irq = regs.orig_eax & 0xff |
計算出中斷號後，do_IRQ()對所接收的中斷進行應答，禁止這條線上的中斷傳遞。在普通的PC機器上，這些操作是由mask_and_ack_8259A()來完成的，該函式由do_IRQ()呼叫。接下來，do_IRQ()需要確保在這條中斷線上有一個有效的處理程式，而且這個程式已經啟動但是當前沒有執行。如果這樣的話， do_IRQ()就呼叫handle_IRQ_event()來執行為這條中斷線所安裝的中斷處理程式，有關處理例子，可以參考linux核心設計分析一書，我這裡就不細講了。在handle_IRQ_event()中，首先是開啟處理器中斷，因為前面已經說過處理器上所有中斷這時是禁止中斷(因為我們說過指定SA_INTERRUPT)。接下來，每個潛在的處理程式在迴圈中依次執行。如果這條線不是共享的，第一次執行後就退出迴圈，否則，所有的處理程式都要被執行。之後，如果在註冊期間指定了SA_SAMPLE_RANDOM標誌，則還要呼叫函式add_interrupt_randomness(),這個函式使用中斷間隔時間為隨機數產生熵。最後，再將中斷禁止(do_IRQ()期望中斷一直是禁止的)，函式返回。該函式做清理工作並返回到初始入口點，然後再從這個入口點跳到函式ret_from_intr().該函式類似初始入口程式碼，以彙編編寫，它會檢查重新排程是否正在掛起，如果重新排程正在掛起，而且核心正在返回使用者空間(也就是說，中斷了使用者程式)，那麼schedule()被呼叫。如果核心正在返回核心空間(也就是中斷了核心本身)，只有在preempt_count為0時，schedule()才會被呼叫(否則，搶佔核心是不安全的)。在schedule()返回之前，或者如果沒有掛起的工作，那麼，原來的暫存器被恢復，核心恢復到曾經中斷的點。在x86上，初始化的彙編例程位於arch/i386/kernel/entry.S,C方法位於arch/i386/kernel/irq.c其它支援的結構類似。
下邊給出PC機上位於/proc/interrupts檔案的輸出結果，這個檔案存放的是系統中與中斷相關的統計資訊，這裡就解釋一下這個表：
上面是這個檔案的輸入，第一列是中斷線(中斷號)，第二列是一個接收中斷數目的計數器，第三列是處理這個中斷的中斷控制器，最後一列是與這個中斷有關的裝置名字，這個名字是通過引數devname提供給函式request_irq()的。最後，如果中斷是共享的，則這條中斷線上註冊的所有裝置都會列出來，如4號中斷。
Linux核心給我們提供了一組介面能夠讓我們控制機器上的中斷狀態，這些介面可以在<asm/system.h>和<asm/irq.h>中找到。一般來說，控制中斷系統的原因在於需要提供同步，通過禁止中斷，可以確保某個中斷處理程式不會搶佔當前的程式碼。此外，禁止中斷還可以禁止核心搶佔。然而，不管是禁止中斷還是禁止核心搶佔，都沒有提供任何保護機制來防止來自其他處理器的併發訪問。Linux支援多處理器，因此，核心程式碼一般都需要獲取某種鎖，防止來自其他處理器對共享資料的併發訪問，獲取這些鎖的同時也伴隨著禁止本地中斷。鎖提供保護機制，防止來自其他處理器的併發訪問，而禁止中斷提供保護機制，則是防止來自其他中斷處理程式的併發訪問。
在linux裝置驅動理論帖裡詳細介紹過linux的中斷操作介面，這裡就大致過一下，禁止/使能本地中斷(僅僅是當前處理器)用：
|
1
2
|
local_irq_disable();local_irq_enable(); |
如果在呼叫local_irq_disable()之前已經禁止了中斷，那麼該函式往往會帶來潛在的危險，同樣的local_irq_enable()也存在潛在的危險，因為它將無條件的啟用中斷，儘管中斷可能在開始時就是關閉的。所以我們需要一種機制把中斷恢復到以前的狀態而不是簡單地禁止或啟用，核心普遍關心這點，是因為核心中一個給定的程式碼路徑可以在中斷啟用餓情況下達到，也可以在中斷禁止的情況下達到，這取決於具體的呼叫鏈。面對這種情況，在禁止中斷之前儲存中斷系統的狀態會更加安全一些。相反，在準備啟用中斷時，只需把中斷恢復到它們原來的狀態：
|
1
2
3
|
unsigned long flags;local_irq_save(flags);local_irq_restore(flags); |
引數包含具體體系結構的資料，也就是包含中斷系統的狀態。至少有一種體系結構把棧資訊與值相結合(SPARC),因此flags不能傳遞給另一個函式(換句話說，它必須駐留在同一個棧幀中)，基於這個原因，對local_irq_save()的呼叫和local_irq_restore()的呼叫必須在同一個函式中進行。前面的所有的函式既可以在中斷中呼叫，也可以在程式上下文使用。
前面我提到過禁止整個CPU上所有中斷的函式。但有時候，好奇的我就想，我幹麼沒要禁止掉所有的中斷，有時，我只需要禁止系統中一條特定的中斷就可以了(遮蔽掉一條中斷線)，這就有了我下面給出的介面：
|
1
2
3
4
|
void disable_irq(unsigned int irq);void disable_irq_nosync(unsigned int irq);void enable_irq(unsigned int irq);void synchronise_irq(unsigned int irq); |
對有關函式的說明和注意，我前邊已經說的很清楚了，這裡飄過。另外，禁止多箇中斷處理程式共享的中斷線是不合適的。禁止中斷線也就禁止了這條線上所有裝置的中斷傳遞，因此，用於新裝置的驅動程式應該傾向於不使用這些介面。另外，我們也可以通過巨集定義在<asm/system.h>中的巨集irqs_disable()來獲取中斷的狀態，如果中斷系統被禁止，則它返回非0，否則，返回0；用定義在<asm/hardirq.h>中的兩個巨集in_interrupt()和in_irq()來檢查核心的當前上下文的介面。由於程式碼有時要做一些像睡眠這樣只能從程式上下文做的事，這時這兩個函式的價值就體現出來了。
最後，作為對這篇部落格的總結，這裡給出我前邊提到的用於控制中斷的方法列表：
