linux核心分析筆記—-中斷和中斷處理常式

       中斷還是中斷，我講了很多次的中斷了，今天還是要講中斷，為啥呢？因為在作業系統中，中斷是必須要講的..

       那麼什麼叫中斷呢， 中斷還是打斷，這樣一說你就不明白了。唉，中斷還真是有點像打斷。我們知道linux管理所有的硬體裝置，要做的第一件事先是通訊。然後，我們天天在說一句話：處理器的速度跟外圍硬體裝置的速度往往不在一個數量級上，甚至幾個數量級的差別，這時咋辦，你總不能讓處理器在那裡傻等著你硬體做好了告訴我一聲吧。這很容易就和日常生活聯絡起來了，這樣效率太低，不如我處理器做別的事情，你硬體裝置準備好了，告訴我一聲就得了。這個告訴，咱們說的輕鬆，做起來還是挺費勁啊！怎麼著，簡單一點，輪訓(polling)可能就是一種解決方案，缺點是作業系統要做太多的無用功，在那裡傻傻的做著不重要而要重複的工作，這裡有更好的辦法---中斷，這個中斷不要緊，關鍵在於從硬體裝置的角度上看，已經實現了從被動為主動的曆史性突破。

       中斷的例子我就不說了，這個很顯然啊。分析中斷，本質上是一種特殊的電訊號，由硬體裝置發向處理器，處理器接收到中斷後，會馬上向作業系統反應此訊號的帶來，然後就由OS負責處理這些新到來的資料，中斷可以隨時發生，才不用操心與處理器的時間同步問題。不同的裝置對應的中斷不同，他們之間的不同從作業系統級來看，差別就在於一個數位識別碼-----中斷號。專業一點就叫插斷要求(IRQ)線,通常IRQ都是一些數值量。有些體繫結構上，中斷好是固定的，有的是動態分配的，這不是問題所在，問題在於特定的中斷總是與特定的裝置相關聯，並且核心要知道這些資訊，這才是最關鍵的,不是嗎？哈哈.

       用書上一句話說：討論中斷就不得不提及異常，異常和中斷不一樣，它在產生時必須要考慮與處理器的時鐘同步，實際上，異常也常常稱為同步中斷，在處理器執行到由於編程失誤而導致的錯誤指令的時候，或者是在執行期間出現特殊情況，必須要靠核心來處理的時候，處理器就會產生一個異常。因為許多處理器體繫結構處理異常以及處理中斷的方式類似，因此，核心對它們的處理也很類似。這裡的討論，大部分都是適合異常，這時可以看成是處理器本身產生的中斷。

       中斷產生告訴中斷控制器，繼續告訴作業系統核心，核心總是要處理的，是不？這裡核心會執行一個叫做中斷處理常式或中斷處理常式的函數。這裡特別要說明，中斷處理常式是和特定中斷相關聯的，而不是和裝置相關聯，如果一個裝置可以產生很多中斷，這時該裝置的驅動程式也就需要準備多個這樣的函數。一個中斷處理常式是裝置驅動程式的一部分，這個我們在linux裝置驅動中已經說過，就不說了，後面我也會提到一些。前邊說過一個問題：中斷是可能隨時發生的，因此必須要保證中斷處理常式也能隨時執行，中斷處理常式也要儘可能的快速執行，只有這樣才能保證儘可能快地恢複中斷代碼的執行。

       但是，不想說但是，大學第一節逃課的情形現在仍記憶猶新：又想馬兒跑，又想馬兒不吃草，怎麼可能！但現實問題或者不像想象那樣悲觀，我們的中斷說不定還真有奇蹟發生。這個奇蹟就是將中斷處理切為兩個部分或兩半。中斷處理常式上半部(top half)---接收到一個中斷，它就立即開始開始執行，但只做嚴格時限的工作，這些工作都是在所有中斷被禁止的情況下完成的。同時，能夠被允許稍後完成的工作延遲到下半部(bottom half)去，此後，下半部會被執行，通常情況下，下半部都會在中斷處理常式返回時立即執行。我會在後面談論linux所提供的是實現下半部的各種機制。

       說了那麼多，現在開始第一個問題：如何註冊一個中斷處理常式。我們在linux驅動程式理論裡講過，通過一下函數可註冊一個中斷處理常式：

int request_irq(unsigned int irq,irqreturn_t (*handler)(int, void *,struct pt_regs *),unsigned long irqflags,const char * devname,void *dev_id)

       有關這個中斷的一些參數說明，我就不說了，一旦註冊了一個中斷處理常式，就肯定會有釋放中斷處理，這是調用下列函數：

void free_irq(unsigned int irq, void *dev_id)

       這裡需要說明的就是要必須要從進程上下文調用free_irq().好了，現在給出一個例子來說明這個過程,首先聲明一個中斷處理常式：

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()的聲明如下：

unsigned int do_IRQ(struct pt_regs regs)

       因為C的調用慣例是要把函數參數放在棧的頂部，因此pt_regs結構包含原始寄存器的值，這些值是以前在彙編入口常式中儲存在棧上的。中斷的值也會得以儲存，所以，do_IRQ()可以將它提取出來，X86的代碼為：

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的中斷操作介面，這裡就大致過一下，禁止/使能本地中斷(僅僅是當前處理器)用：

local_irq_disable();local_irq_enable();

       如果在調用local_irq_disable()之前已經禁止了中斷，那麼該函數往往會帶來潛在的危險，同樣的local_irq_enable()也存在潛在的危險，因為它將無條件的啟用中斷，儘管中斷可能在開始時就是關閉的。所以我們需要一種機制把中斷恢複到以前的狀態而不是簡單地禁止或啟用，核心普遍關心這點，是因為核心中一個給定的代碼路徑可以在中斷啟用餓情況下達到，也可以在中斷禁止的情況下達到，這取決於具體的調用鏈。面對這種情況，在禁止中斷之前儲存中斷系統的狀態會更加安全一些。相反，在準備啟用中斷時，只需把中斷恢複到它們原來的狀態：

unsigned long flags;local_irq_save(flags);local_irq_restore(flags);

       參數包含具體體繫結構的資料，也就是包含中斷系統的狀態。至少有一種體繫結構把棧資訊與值相結合(SPARC),因此flags不能傳遞給另一個函數(換句話說，它必須駐留在同一個棧幀中)，基於這個原因，對local_irq_save()的調用和local_irq_restore()的調用必須在同一個函數中進行。前面的所有的函數既可以在中斷中調用，也可以在進程上下文使用。

       前面我提到過禁止整個CPU上所有中斷的函數。但有時候，好奇的我就想，我幹麼沒要禁止掉所有的中斷，有時，我只需要禁止系統中一條特定的中斷就可以了(屏蔽掉一條中斷線)，這就有了我下面給出的介面：

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()來檢查核心的當前內容相關的介面。由於代碼有時要做一些像睡眠這樣只能從進程上下文做的事，這時這兩個函數的價值就體現出來了。

       最後，作為對這篇部落格的總結，這裡給出我前邊提到的用於控制中斷的方法列表：