在硬件上，中斷源可以通過中斷控制器向CPU提交中斷，進而引發(fā)中斷處理程序的執(zhí)行，不過這種硬件中斷體系每一種CPU都不一樣，而Linux作為操作系統，需要同時支持這些中斷體系，如此一來，Linux中就提出了軟中斷的概念，也有人叫內核中斷，其本質就是使用統一的方式對不同硬件中斷體系中的中斷號進行再映射，在操作系統中操作的中斷號都是這些映射過的軟中斷號。就是下圖中的irq_num

Linux內核中定義了名為irq_desc的中斷例程描述符表來描述中斷服務例程，每一個irq_desc對象數組中的下標就是軟中斷號。其中的struct irqaction對象描述了這個中斷服務例程的中斷的具體信息。

//include/linux/irqdesc.h 40 struct irq_desc { 41 struct irq_data irq_data; 42 unsigned int __percpu *kstat_irqs; 43 irq_flow_handler_t handle_irq; 44 #ifdef CONFIG_IRQ_PREFLOW_FASTEOI 45 irq_preflow_handler_t preflow_handler; 46 #endif 47 struct irqaction *action; /* IRQ action list */ 48 unsigned int status_use_accessors; 49 unsigned int core_internal_state__do_not_mess_with_it; 50 unsigned int depth; /* nested irq disables */ 51 unsigned int wake_depth; /* nested wake enables */ 52 unsigned int irq_count; /* For detecting broken IRQs */ 53 unsigned long last_unhandled; /* Aging timer for unhandled count */ 54 unsigned int irqs_unhandled; 55 raw_spinlock_t lock; 56 struct cpumask *percpu_enabled; 57 #ifdef CONFIG_SMP 58 const struct cpumask *affinity_hint; 59 struct irq_affinity_notify *affinity_notify; 60 #ifdef CONFIG_GENERIC_PENDING_IRQ 61 cpumask_var_t pending_mask; 62 #endif 63 #endif 64 unsigned long threads_oneshot; 65 atomic_t threads_active; 66 wait_queue_head_t wait_for_threads; 67 #ifdef CONFIG_PROC_FS 68 struct proc_dir_entry *dir; 69 #endif 70 int parent_irq; 71 struct module *owner; 72 const char *name; 73 } ____cacheline_internodealigned_in_smp; 74

76 extern struct irq_desc irq_desc[NR_IRQS]; //NR_IRQS表示中斷源的數目

//linux/interrupt.h104 //一個irq action的描述結構105 struct irqaction { 106 irq_handler_t handler;107 void *dev_id;108 void __percpu *percpu_dev_id;109 struct irqaction *next;110 irq_handler_t thread_fn;111 struct task_struct *thread;112 unsigned int irq;113 unsigned int flags;114 unsigned long thread_flags;115 unsigned long thread_mask;116 const char *name;117 struct proc_dir_entry *dir;118 } ____cacheline_internodealigned_in_smp;

struct irqaction
--105-->handler: 中斷處理函數
--106-->name: 設備名
--107-->dev_id: 設備識別id
--109-->next: 指向下一個irqaction的指針
--110-->irq: 硬件中斷號！！！
--113-->flags:IRQF_DISABLED .etc
--110-->thread_fn: 線程中斷的中斷處理函數
--111-->thread: 線程中斷的線程指針
--114-->thread_flags:?與@thread關聯的flags
--115-->thread_mask:?追蹤@thread?activity的位掩碼
--116-->dir: 指向proc/irq/NN/name的入口指針

raw_local_irq_save(x) //禁止所有中斷raw_local_irq_enable //取消禁止中斷

寫中斷處理程序

1. 編寫中斷處理函數

下面這個就是中斷處理程序的原型，中斷發(fā)生后，內核會將軟中斷號和注冊時的data作為參數傳入。中斷處理程序ISR是在中斷發(fā)生時被調用的用來處理中斷的函數，不是進程上下文，在中斷期間運行，不能執(zhí)行可能休眠的操作，不能同用戶空間交換數據，不能調用schedule()函數放棄調度
實現中斷處理有一個原則：盡可能快的處理并返回，冗長的計算處理工作應該交給tasklet或任務隊列在安全的時間內進行。此外，硬件系統中常使用共享中斷，即多個設備共享一根線。即該(軟硬)中斷號可以被多個設備共享，這在實際的硬件連接中經常見到，可以節(jié)約很多資源，但是如此一來，就給軟件的編寫的提出了要求，內核給出的方案是一旦接收到來自一條中斷線的中斷，它就會循環(huán)執(zhí)行所有注冊到該中斷線(->硬中斷號->軟中斷號)的handler，這樣，每一個handler就有義務判斷到底是不是自己負責的設備來的中斷，handler原型的dev_id也正是為了這個目的而存在，我們可以將該handler負責的設備的中斷狀態(tài)寄存器的地址作為dev_id和handler一起注冊，當內核遍歷執(zhí)行所有的handler的時候，會將每一個中斷的dev_id作為參數依次傳入每一個handler，在每一個handler內部首次通過讀取這個寄存器來快速判斷是否是自己負責的設備發(fā)出的。這也就是共享中斷必須設置dev_id參數的原因之一。至此，就可以實現多個設備對這一中斷線的"shared"。注意，對于這個"shared"，并不是在時間上允許多個中斷同時發(fā)生，而是一種空間上的、中斷號上的"shared",此外，這個"shared"和三星芯片中常見的Shared Peripheral Interrupts(SPI)不是一回事，后者表示這個中斷可以被GIC router到任意一個CPU中。

88 typedef irqreturn_t (*irq_handler_t)(int, void *);

irqreturn_t xxx_interrupt(int irq, void *dev_id){ ... int status = read_irq_status(); /* 讀取相應的寄存器獲取中斷源 */ if(!is_myirq(dev_id,status)){ /* 判斷是否是本設備中斷 */ return IRQ_NONE; } /* 中斷處理程序 */ return IRQ_HANDLED}

2. 注冊中斷處理函數

下面這個就是注冊中斷的API，flags取值在"interrupt.h"有定義，常用的有IRQF_DISABLED和IRQF_SHARED，前者表示中斷程序調用時屏蔽所有中斷，"所有"指的是屏蔽所有中斷線的中斷，本中斷線的中斷本來就是屏蔽的，內核默認不允許中斷嵌套。IRQF_SHARED表示多個設備共享中斷，即該中斷線上連接了多個相同或不同的設備。
除了中斷類型，flags還需要"位或"上觸發(fā)方式，eg：IRQF_DISABLED|IRQF_TRIGGER_RISING

/** * @flags:中斷標志位。 * @dev_id用于共享中斷，用來標識是哪個設備觸發(fā)了中斷，通常傳入相應設備的中斷狀態(tài)寄存器的地址 * @name 是中斷名稱，可以在/proc/interrupt中看到 */int requst_irq(unsigned int irq，irq_handler_t handler, unsigned long flags, const char *name,void * dev_id);

3. 釋放中斷處理函數

中斷號也是一種系統資源，使用完畢后要釋放，注意，free_irq的第二個參數應當與request_irq()中最后一個參數相同，這樣才能將這個handler從這個中斷線中的handler鏈表中刪除。

/** * free_irq - 釋放irq */void free_irq(unsigned int irqno,void * dev_id);

底半部

中斷不屬于進程上下文，所以不能被內核調度，如果進入了中斷處理函數，就只能將其執(zhí)行完畢，不能被打斷，這樣帶來的一個問題是如果在中斷處理函數中執(zhí)行耗時操作，就會極大的影響系統性能，為了解決這個問題，Linux內核中提出了中斷頂半部和`底半部(bottom half)的概念，對于耗時的中斷處理程序，將重要的、必要的操作放在頂半部執(zhí)行，這部分和傳統的中斷概念一樣，一旦開始就必須執(zhí)行完畢;將中斷處理程序中耗時的，不那么緊要的操作放在底半部，防止整個中斷處理程序過多的占用系統資源。
Linux內核提供的3種中斷底半部機制：工作隊列，tasklet,軟中斷。其中軟中斷機制是內核底層的機制，包括定時器，異步通知等很多機制都是基于軟中斷，開發(fā)者不應該直接操作，所以這里僅討論前兩種

Tasklet

每個tasklet都和一個函數相關聯，當tasklet被運行時，該函數就被調用，并且tasklet可以調度自己。

//定義一個處理函數void my_tasklet_fcn(unsigned long){}//定義一個tasklet結構my_tasklet，并與處理函數相關聯，DECLARE_TASKLET(my_tasklet,my_tasklet_fcn,data);//調度tasklettasklet_schedule(&my_tasklet);

工作隊列

工作隊列和tasklet類型，tasklet多運行于中斷上下文，而工作隊列多運行與進程上下文
此外，tasklet中不能睡眠，而工作隊列處理函數允許睡眠(正是由于它被當作內核線程被調度)

//定義一個工作隊列struct work_queue my_wq;//定義一個處理函數void my_wq_fcn(unsigned long){}//初始化工作隊列并將其與處理函數綁定INIT_WORK(&my_wq,my_wq_fcn);//調度工作隊列執(zhí)行schedule_work(&my_wq);

static irqreturn_t handler_t(int irq, void *dev){ //top half schedule_work(&ws); return IRQ_HANDLED;}void work_func(struct work_struct *work){ //bottom half ssleep(3);}static int __init demo_init(void){ ... INIT_WORK(&ws, work_func); request_irq(irq, handler_t, IRQF_TRIGGER_RISING, "demo", NULL); ...}

其他API

除了上述API，內核還提供了其他的中斷操作API，在內核代碼中被廣泛使用。

raw_local_irq_save(x) //禁止所有中斷raw_local_irq_enable //取消禁止中斷//下面三個函數用于可編程中斷控制器，對所有CPU都有效//屏蔽一個中斷void disable_irq(int irq); //立即返回void disable_irq_nosync(); //等待目前中斷處理返程//使能一個中斷void enable_irq()
?