http://blog.csdn.net/jansonzhe/article/details/48786207

在之前我所寫的Linux驅動程式中，會經常使用到中斷機制，像CC1100高頻驅動、倒車雷達驅動等等。但所用到的中斷機制都基本上是用到中斷的頂半部，即：編寫中斷處理函式，通過request_irq函式申請中斷，這樣當中斷來臨的時候，就會自動執行中斷處理程式裡面的內容。之所以沒有使用到中斷的底半部，是因為我們這些驅動程式中，中斷處理函式一般都能被很快執行完，同時也不會存在有任何休眠的動作，因此使用中斷的頂半部對於我們這些驅動程式來說，反而相對簡單一些。因此這也就得出，並不是任何中斷程式都一定會使用到中斷的底半部。

中斷頂半部

對於中斷的頂半部，我想大部分的關於Linux驅動的書上都會有詳細的講解，並且這一塊理解和實踐起來都比較容易，但這裡我需要講解的是關於共享中斷的這一部分，因為這一塊可能對於一些初學者會有一點難度。

共享中斷是指多個裝置共享一根中斷線（中斷線在這裡可以理解為中斷號，也就是說多個裝置共享一箇中斷號），為什麼會有這種情況發生，因為在Linux核心中，中斷線的數目是有限的，如果每一個裝置都使用一根中斷線的話，中斷線肯定是不夠的，所以聰明的Linux核心設計師們就提出了共享中斷這一理念。這裡理念的主要目的就是可以在一根中斷線上搭載多箇中斷裝置。那麼好了，現在問題也來了，既然都在同一個中斷線上，如果中斷來了的話，要如何判斷該中斷來自於哪一個裝置呢？其實對於Linux核心來說，要判斷其來自哪一個裝置，其需要做兩步工作。當一箇中斷來臨時，Linux核心會遍歷該中斷線上所有註冊了的中斷處理程式，在該中斷處理程式中，就會迅速判斷到底是來自於哪一個硬體裝置。而在中斷程式中如何來判斷呢？這就需要相應產生中斷的硬體裝置來支援了。例如可能中斷處理程式會檢查一下該處理程式對應的硬體裝置的某一暫存器的狀態來判斷是否該裝置發生了中斷，如果是該裝置發出的中斷，就執行接下來的處理函式。如果不是，就立即返回（應該返回IRQ_RETVAL(IRQ_NONE)

）。

首先我們來看一下在申請共享中斷的過程與一般申請中斷有哪些不同。

我們知道申請註冊中斷的函式是：

1. request_irq(unsigned int irq, irq_handler_t handler, unsigned long flags,  
2.         constcharchar *name, voidvoid *dev)  
3. {  
4.     return request_threaded_irq(irq, handler, NULL, flags, name, dev);  
5. }  

1. 如果我們要申請共享中斷函式的話，flag標誌位必須還要指定一個IRQF_SHARED（即flag再“ | ”上一個IRQF_SHARED），注意，該中斷線的每一箇中斷裝置在申請中斷的時候都必須要加上該標誌位。
2. 對於每一個註冊的中斷處理程式來說，最後一個引數dev必須是唯一的（這是共享中斷所明確要求的）。為了確保dev引數值是唯一的。可以將dev引數的值設為指向申請中斷函式的裝置結構體指標即可（我們的CC1101和倒車雷達驅動都是這麼幹的）。而且由於中斷處理函式可能會用到裝置結構體的資料，因此這是一個一箭雙鵰的方法。對於共享中斷處理程式，dev的引數值不能為NULL。

中斷上下文

在這裡順便提一下中斷上下文，當我們執行一箇中斷處理函式時，核心就會處於中斷上下文（Interrupt Context）中。與程序上下文不同，中斷上下文與程序並沒有什麼關係。與current巨集也沒有任何關係，儘管此時若使用的current標誌位的話，其任然是指向被中斷的程序。由於中斷上下文不依賴與程序，因此中斷上下文不能休眠，不能在中斷上下文中呼叫某些可能引起休眠的函式。

由於中斷上下文可以打斷其他正在執行的程式碼，因此，中斷上下文在執行時間上由嚴格的時間限制。中斷上下文中的程式碼需要儘可能簡潔，儘量不要使用迴圈或者是耗時比較長的函式來處理中斷任務。這是由於中斷上下文已經打斷了其他正在執行的程式碼，甚至可能是其他的中斷處理程式，因此中斷處理程式應該快速地執行完，否則可能會使其他被打斷的程式長時間等待而造成系統性能下降甚至崩潰。當然，在中斷上下文中處理複雜耗時的任務也在所難免，但最好將這部分任務放在中斷的底半部（主要因為中斷的底半部，可以被其他甚至是同類型的中斷打斷，並且中斷底半部函式是非同步執行。）。這樣既可以很快地執行完中斷處理程式（儘快回覆被中斷的程式碼），又可以在中斷程式中完成很複雜的任務。後面的軟中斷或者是tasklet都屬於中斷的上下文中。

在Linux2.6核心中，中斷處理程式擁有自己的棧，每一個處理器一個，大小為一頁（4KB），儘管中斷棧並不算大，但平均可用棧空間要比Linux核心的其他程式大得多。因為中斷程式把這一頁據為己有。在我們編寫中斷處理程式時，並不需要關心如何設定中斷棧或核心棧的大小，總之，儘量節約中斷棧的空間就行了。

中斷的底半部

下面我們來開始講解中斷底半部，如果用一個詞來形容底半部的功能，就是“延遲執行”，為什麼要這樣說呢，後面分析過後就會深刻理解這一點了。在中斷的上半部，即中斷處理程式結束前，當前的中斷線在所有的處理器上都會被遮蔽，如果在申請中斷線時使用了IRQF_DISABLED，那麼情況會更加糟糕，在中斷處理程式執行時會禁止所有的本地中斷。因此儘可能地縮短中斷被遮蔽的時間對系統的響應能力和效能都至關重要。因此，要將耗時較長的任務放到底半部延遲執行。因為底半部並不禁止其他中斷上半部的執行（哪怕是自己的中斷處理函式）。對於中斷底半部的實現方式一共有三種；

1. 採用軟中斷的方式
2. 採用tasklet微執行緒
3. 採用工作佇列

下面我們分別介紹這三種實現中斷底半部的方式 軟中斷 軟中斷使核心可以執行延遲任務，由於其運作方式與之前的中斷類似，並且完全由軟體實現，因此稱之為軟中斷。在講解軟中斷之前，我們先來看一下軟中斷的一個模型圖：
我們可以看到，所有的中斷線上的中斷都需要經過do_IRQ函式，執行該函式，需要一個irq的引數，也就是中斷號。然後do_IRQ函式便會輪詢得執行該中斷線上的所以中斷處理程式，該實現方式主要是在do_IRQ函式中呼叫handle_IRQ_event函式實現。handle_IRQ_event會執行irq所在的中斷線上的所有的中斷處理函式。好了，現在如果我們執行完了handle_IRQ_event函式後，我們會在do_IRQ中呼叫irq_exit函式，該函式才是負責呼叫和處理待決的軟中斷。首先我們來看一下這個函式的原始碼：

1. void irq_exit(void)  
2. {  
3.     account_system_vtime(current);  
4.     trace_hardirq_exit();  
5.     sub_preempt_count(IRQ_EXIT_OFFSET);  
6.     if (!in_interrupt() && local_softirq_pending())  
7.  //判斷是否有軟中斷被請求，主要是看是否有執行raise_softirq函式，
8.         invoke_softirq(); //用於喚醒軟中斷，即會啟用do_softirq函式
9.     rcu_irq_exit();  
10. #ifdef CONFIG_NO_HZ
11.     /* Make sure that timer wheel updates are propagated */
12.     if (idle_cpu(smp_processor_id()) && !in_interrupt() && !need_resched())  
13.         tick_nohz_stop_sched_tick(0);  
14. #endif
15.     preempt_enable_no_resched();  
16. }  

一旦我們啟用軟中斷，呼叫do_softirq函式，就說明程式已經進入軟中斷環境了。與do_IRQ所處的中斷的頂半部不同，處於軟中斷環境中，是可以被其他中斷程式打斷的，甚至是處於同一中斷線的中斷，也因為此，所以軟中斷可以執行一些稍微時間長一點的任務，也不會遲滯系統對中斷的反應時間。
下面我將詳細介紹有關do_softirq函式的實現原理和過程，因為只有瞭解該過程，才能充分理解軟中斷的工作原理。 軟中斷由一個softirq_action結構體表示，在該結構體中只定義了一個函式指標

1. struct softirq_action  
2. {  
3.     void    (*action)(structsoftirq_action *); //函式指標名為action，其中引數型別為一個
4. };  

其實這個函式指標就是指向該軟中斷的處理函式。 當我們需要使用軟中斷時，首先要想Linux核心註冊軟中斷，註冊的內容包括軟中斷的型別和軟中斷處理函式指標。所以這也就知道了為什麼說軟中斷由一個softirq_action結構體表示。因為軟中斷最為核心的地方就是軟中斷處理函式。 在驅動程式中，如果我們要想註冊軟中斷，我們需要使用open_softirq函式

1. void open_softirq(int nr, void (*action)(structsoftirq_action *))  
2. {  
3.     softirq_vec[nr].action = action; //指定軟中斷處理函式指標。
4. }  

我們可以發現，這裡出現了一個softirq_vec陣列，該陣列型別當然是softirq_action型別的了，陣列的下標表示了不同的軟中斷型別。下標越小，軟中斷的優先順序越高。下面是不同的下標表示不同的型別的軟中斷，其用一個列舉來表示。

1. enum
2. {  
3.     HI_SOFTIRQ=0, //優先順序最高的軟中斷，用於tasklet
4.     TIMER_SOFTIRQ,  
5.     NET_TX_SOFTIRQ, //傳送網路資料的軟中斷
6.     NET_RX_SOFTIRQ,  
7.     BLOCK_SOFTIRQ,  
8.     BLOCK_IOPOLL_SOFTIRQ,  
9.     TASKLET_SOFTIRQ, //tasklet軟中斷
10.     SCHED_SOFTIRQ,  
11.     HRTIMER_SOFTIRQ,  
12.     RCU_SOFTIRQ,    /* Preferable RCU should always be the last softirq */
13.     NR_SOFTIRQS   //該列舉值就是當前Linux核心允許註冊的最大軟中斷數
14. };  

這裡需要注意的是softirq_vec對於整個Linux核心是全域性的，所以任何一個軟中斷的處理程式都是全域性唯一的，即softirq_vec[nr].action = action中一旦指定了其軟中斷處理程式的方法，則這個型別的軟中斷的處理程式就確定了。
當我們編寫了含有softirq_action引數的軟中斷處理程式，並且通過open_softirq函式註冊完之後（open_softirq函式的功能其實很簡單，就是根據nr指定的軟中斷型別定位當前驅動的softirq_action陣列的相應元素，然後將action指定的軟中斷處理函式的指標賦給softirq_vec[nr].action，注意這裡的softirq_vec是全域性的。），我們就可以使用軟中斷了，一般怎麼使用軟中斷呢？ 前面我們知道，如果在還沒有開啟Ksoftirq執行緒的情況下，我們會在中斷頂半部的do_IRQ中呼叫irq_exit函式，而該函式會喚醒軟中斷，即會執行do_softirq函式，所以歸根結底，要想執行軟中斷，必須得要執行do_IRQ函式，但是是不是隻要我們在呼叫do_IRQ函式之前，註冊了軟中斷函式，我們的軟中斷函式就會被執行了呢？答案當然是否定的。因為如果這樣的話，那每一次中斷結束時，所有的軟中斷處理程式都得執行了，不管這個軟中斷處理程式是否跟這個中斷線有關。所以呀，要想do_softirq函式只執行我們想要的軟中斷處理程式的話，應該需要用raise_softirq函式將我們想要執行的軟中斷處理程式掛起。

1. void raise_softirq(unsigned int nr)  
2. {  
3.     unsigned long flags;  
4.     local_irq_save(flags); //儲存中斷狀態，禁止中斷
5.     raise_softirq_irqoff(nr); //掛起相應的中斷型別
6.     local_irq_restore(flags); //恢復中斷。
7. }  

所以其實raise_softirq函式真正呼叫的是raise_softirq_irqoff(nr)函式，同時從這裡我們也知道了，一個軟中斷型別，只能對應一個軟中斷處理程式，而若要使用tasklet型別的軟中斷的話，就必須要執行raise_softirq_irqoff(TASKLET_SOFTIRQ)函式。 相應型別的軟中斷被掛起之後，下面我們就來看看Linux是如何執行它的吧，通過上面我給出的那個軟中斷的模型圖，我們可以知道執行軟中斷的函式是do_softirq函式，這個函式是執行一切軟中斷處理程式的根本，也就是說任何一個軟中斷處理程式都應該經過do_softirq函式呼叫的，好了我們現在來看看do_softirq的廬山真面目吧

1. asmlinkage void do_softirq(void)  
2. {  
3.     __u32 pending;  
4.     unsigned long flags;  
5.     if (in_interrupt())  
6.         return;  
7.     local_irq_save(flags);  
8.     pending = local_softirq_pending(); //再獲取pending標誌位，是否有軟中斷處理程式被raise
9.     if (pending)  
10.         __do_softirq(); //如果有，則執行_do_softirq函式
11.     local_irq_restore(flags);  
12. }  

所以do_softirq函式真正起作用的是_do_softirq函式。

1. asmlinkage void __do_softirq(void)  
2. {  
3.     structsoftirq_action *h;  
4.     __u32 pending;  
5.     int max_restart = MAX_SOFTIRQ_RESTART;  
6.     int cpu;  
7.     pending = local_softirq_pending();  
8.     account_system_vtime(current);  
9.     __local_bh_disable((unsigned long)__builtin_return_address(0),  
10.                 SOFTIRQ_OFFSET);  
11.     lockdep_softirq_enter();  
12.     cpu = smp_processor_id();  
13. restart:  
14.     /* Reset the pending bitmask before enabling irqs */
15.     set_softirq_pending(0);  
16.     local_irq_enable();  
17.     h = softirq_vec;  
18.     do {  
19.         if (pending & 1) {    //將pending不同的為與1相"&"，來確定哪種型別的軟中斷被掛起了
20.             unsigned int vec_nr = h - softirq_vec; //獲取softirq_vec陣列的下標值，該下標值也就確定了軟中斷屬於什麼型別了
21.             int prev_count = preempt_count();  
22.             kstat_incr_softirqs_this_cpu(vec_nr);  
23.             trace_softirq_entry(vec_nr);  
24.             h->action(h);  //在這裡執行軟中斷的處理函式action
25.             trace_softirq_exit(vec_nr);  //執行完該軟中斷處理程式之後，就應該將掛起的標誌位重新置0，將相應的_softirq_pending
26.             if (unlikely(prev_count != preempt_count())) {  
27.                 printk(KERN_ERR "huh, entered softirq %u %s %p"
28.                        "with preempt_count %08x,"
29.                        " exited with %08x?\n", vec_nr,  
30.                        softirq_to_name[vec_nr], h->action,  
31.                        prev_count, preempt_count());  
32.                 preempt_count() = prev_count;  
33.             }  
34.             rcu_bh_qs(cpu);  
35.         }  
36.         h++;  
37.         pending >>= 1;  
38.     } while (pending);  
39.     local_irq_disable();  
40.     pending = local_softirq_pending();  
41.     if (pending && --max_restart)  
42.         goto restart;  
43.     if (pending)  //重新獲取的pending，如果其不為0，說明又有新的軟中斷處理程式被掛起，如果待處理的軟中斷程式過多，就應該開啟Ksoftirq執行緒。從而達到延時目的
44.         wakeup_softirqd(); //開啟Ksoftirq執行緒（軟中斷處理執行緒），即將Ksoftirq執行緒加入至可執行佇列
45.     lockdep_softirq_exit();  
46.     account_system_vtime(current);  
47.     __local_bh_enable(SOFTIRQ_OFFSET);  
48. }  

關於Ksoftirq執行緒後面會詳細講解。到此軟中斷的工作原理就全部講解完了，理解了軟中斷的機制，再去理解tasklet就容易很多了。

tasklet微執行緒 軟中斷是將操作推遲到將來某一個時刻執行的最有效的方法。由於該延遲機制處理複雜，多個處理器可以同時並且獨立得處理（即do_softirq函式可以被多個CPU同時執行），並且一個軟中斷的處理程式可以在多個CPU上同時執行，因此處理程式必須要被設計為完全可重入和執行緒安全的。此外臨界區必須用自旋鎖保護。由於軟中斷因為這些原因就顯得太過於麻煩，因此引入tasklet機制，就變得很有必要了。tasklet是基於軟中斷實現的，在我們上面講軟中斷的時候知道，tasklet確切的說應該是軟中斷的一個型別，所以根據軟中斷的性質，一個軟中斷型別對應一個軟中斷處理程式action。同理，也可以推出tasklet也會對應於一個唯一的action。可能講到這裡會有讀者覺得，既然一個tasklet型別的軟中斷只對應一個軟中斷處理程式，那麼我可能在一個驅動程式中使用多個tasklet怎麼辦？或者是有多個驅動程式裡面都要使用tasklet又怎麼辦？要回答這個問題，我們就要了解tasklet另一個重要的性質。那就是，每一個CPU都會有自己獨立的tasklet佇列，雖然一個tasklet型別的軟中斷只對應一個action處理程式，但是我們可以在該處理程式中輪詢執行一個tasklet佇列，佇列裡面的每一個tasklet_struct都會對應一個tasklet處理函式，這樣當我們的驅動程式中需要使用到tasklet的時候，只要往這個tasklet佇列加入我們自定義的tasklet_struct物件就可以了。同時，由於每一個CPU都會有一個tasklet佇列，並且每一個CPU只會執行自己tasklet佇列裡面的tasklet_struct物件，因此tasklet並不需要自旋鎖的保護（當然這隻能是對同一個tasklet而言，如果多個不同的tasklet需要使用同一資源的話，仍需要自旋鎖的保護，後面瞭解了tasklet機制之後就會明白這一點），因此這樣就降低了對tasklet處理函式的要求。 對於一個tasklet物件是通過一個tasklet_struct結構體來描述的，該結構體定義在include\linux\interrupt.h檔案中

1. struct tasklet_struct  
2. {  
3.     structtasklet_struct *next; //連結下一個tasklet_struct物件，以構成一個tasklet佇列
4.     unsigned long state;  //該tasklet的執行狀態標誌位
5.     atomic_t count;     //該tasklet被引用的次數標誌位，當count為0時，表示已啟用可用
6.     void (*func)(unsigned long); //該tasklet的處理函式指標，也是tasklet的核心所在
7.     unsigned long data;   //給上面的處理函式傳的引數。
8. };  

下面就給出一個tasklet的佇列示意圖

理解這個tasklet佇列非常有用，這樣我們就可以充分理解tasklet的工作機制了。從上面這個佇列，我們可以看到這個佇列的頭是一個名叫tasklet_vec的tasklet_head結構體，我們來看看tasklet_head結構體體

1. struct tasklet_head  
2. {  
3.     structtasklet_struct *head;  
4.     structtasklet_struct **tail;  
5. };  

可以看到，裡面有兩個元素，第一個是一個tasklet_struct結構體指標，在tasklet_vec中，這個用來指向與其最近的一個tasklet_struct結構體。另外一個是一個tasklet_struct型別的指標的指標，幹嘛用的呢，從上圖我們可以看到，它指向的是tasklet佇列最後一個tasklet_struct的next指標的地址。這樣一個tasklet_head就可以維護一個tasklet隊列了。這裡需要注意的是，當這個tasklet列表沒有一個tasklet_struct元素時，它的指向是這樣的：

通過這兩個示意圖，我們也知道了如何往該佇列增加tasklet_struct物件了，那就是將最後一個tasklet_sturct的next指標指向新加的tasklet_struct物件，同時將列表頭的tail指標的指標指向新加的tasklet_struct結構體的next指標的地址。下面我們看看具體新增的程式碼：

1. tasklet_struct * t;  
2. * _get_cpu_var(tasklet_vec).tail = t;  
3. _get_cpu_var(tasklet_vec).tail = &(t->next);  

初學者在第一次看到段程式碼時，一般都看不太懂，即便是已經看懂了我上面話的tasklet佇列示意圖。其實這段程式碼的目的非常簡單，就是將新的tasklet_struct指標t加入tasklet佇列，需要注意的是_get_cpu_var(變數名)的作用是獲取獨屬於該CPU的tasklet_vec變數。要看懂這兩行程式碼需要有較強的C語言功底，尤其是要對指標的指標理解深刻。 首先我們來看第一行程式碼： *_get_cpu_var(tasklet_vec).tail = t;
將t所指向的地址賦給指標的指標tail，我們知道 *tail 表示的是其指向指標所指向的地址（在這裡有*tail == head 或者是 *tail == tasklet_struct ->next），而對於tail我們知道，其有兩種情況，第一種是指向最後一個tasklet_struct物件的next指標的地址，因此如果我們執行了*_get_cpu_var(tasklet_vec).tail = t;就表示了最後一個tasklet_struct物件的next的指向也發生變化了，即next指向了新的tasklet_struct；如果是第二種情況的話，即tail指向的是head指標的地址，那麼也可以知道執行*_get_cpu_var(tasklet_vec).tail = t;之後，head便會指向新的tasklet_struct結構體t。 第二行程式碼： _get_cpu_var(tasklet_vec).tail = &(t->next);
這行程式碼很簡單，就是將tail指標指向新的tasklet_struct的next地址。
瞭解了上面的新增tasklet_struct物件之後，下面我們就可以分析tasklet的工作呼叫機制了。我們知道每一個軟中斷型別都會對應一個action（軟中斷處理程式），所以tasklet型別的軟中斷同樣也有其唯一對應的action（一般其他型別軟中斷的action都是由使用者自己編寫，但是tasklet不一樣，Linux設計師已經幫我們實現了。所以也是因為這樣，tasklet被廣泛應用於驅動程式中。）

1. staticvoid tasklet_action(structsoftirq_action *a)  
2. {  
3.     structtasklet_struct *list;  
4.     local_irq_disable();  //禁止本地中斷
5.     list = __this_cpu_read(tasklet_vec.head); //獲取本地中斷的tasklet_vec.head指標的指向
6.     __this_cpu_write(tasklet_vec.head, NULL);  //將tasklet_vec.head賦值為null
7.     __this_cpu_write(tasklet_vec.tail, &__get_cpu_var(tasklet_vec).head);  //將tasklet_vec.tail賦值為head的地址
8.     local_irq_enable();  
9.     while (list) {  
10.         structtasklet_struct *t = list;  
11.         list = list->next;  
12.         if (tasklet_trylock(t)) { //主要是判斷該tasklet是否處於run狀態，如果處於run狀態的話，就從新將其放入tasklet_vec佇列中
13.             if (!atomic_read(&t->count)) {  
14.                 if (!test_and_clear_bit(TASKLET_STATE_SCHED, &t->state))  
15.                     BUG();  
16.                 t->func(t->data); //執行tasklet的處理函式
17.                 tasklet_unlock(t);  
18.                 continue;  
19.             }  
20.             tasklet_unlock(t);  
21.         }  
22.         local_irq_disable();  
23.         t->next = NULL;  
24.         *__this_cpu_read(tasklet_vec.tail) = t;  //如果tasklet正在被其他CPU執行，那麼就將該tasklet重新裝入佇列現在再來看這兩行程式碼就應該熟悉了吧
25.         __this_cpu_write(tasklet_vec.tail, &(t->next));  
26.         __raise_softirq_irqoff(TASKLET_SOFTIRQ); //將tasklet掛起，等待下一次呼叫do_softirq函式的時候，這些加入tasklet佇列的tasklet_struct物件就會被執行。
27.         local_irq_enable();  
28.     }  
29. }  

接下來我們再來看tasklet一個非常重要的函式，就是tasklet_schedule，這個函式通常用於中斷處理程式中，用於將tasklet_struct加入所在CPU的tasklet佇列，同時將tasklet軟中斷掛起。因為我們知道，在中斷的上半部中的irq_exit函式中，會啟用do_softirq函式，所以在中斷處理程式中使用tasklet_schedule函式就顯得特別必要。下面我們來看一下tasklet_schedule函式的原始碼：

1. staticinlinevoid tasklet_schedule(structtasklet_struct *t)  
2. {  
3.     if (!test_and_set_bit(TASKLET_STATE_SCHED, &t->state))  
4.         __tasklet_schedule(t); //呼叫_tasklet_schedule函式
5. }  

這裡要說明一下test_and_set_bit(TASKLET_STATE_SCHED, &t->state)函式，這個函式的目的是首先判斷t->state是否是TASKLET_STATE_SCHED，如果是就返回TASKLET_STATE_SCHED，如果不是則將t->state設定為TASKLET_STATE_SCHED，同時返回t->state原來的值。所以這裡要執行if後面的程式碼，就必須要t->state原來的值為0，即該tasklet是一個全新的tasklet，沒有被用過。我們再來看看_tasklet_schedule函式：

1. void __tasklet_schedule(structtasklet_struct *t)  
2. {  
3.     unsigned long flags;  
4.     local_irq_save(flags); //禁止本地中斷，因為tasklet_vec是本地CPU的公共資源，在一個程式正在使用時，肯定不能被其他程式同時使用，這樣被導致安全問題。
5.     t->next = NULL;  
6.     *__this_cpu_read(tasklet_vec.tail) = t;  
7.     __this_cpu_write(tasklet_vec.tail, &(t->next));  //這兩行程式碼很熟悉吧
8.     raise_softirq_irqoff(TASKLET_SOFTIRQ);  //後面當然也很熟悉
9.     local_irq_restore(flags); //恢復本地中斷
10. }  

在我們驅動程式中若要使用tasklet，首先我們還必須要建立一個tasklet_struct物件，通常建立tasklet_struct物件一共有兩種方式； 一種是靜態的建立方式，採用define這種預編譯的方式，這裡可以使用一個庫預編譯命令：

1. DECLARE_TASKLET(name, func, data)    //count = 0；處於啟用狀態
2. DECLARE_TASKLET_DISABLED(name, func, data) //count = 1；處於未啟用狀態

第二種是動態建立方式：

1. staticstruct tasklet_struct my_tasklet;  
2. tasklet_init(&my_tasklet， tasklet_handler, 0); //count = 0，處於啟用狀態。

其中tasklet_init函式也是系統函式，可以直接使用的

1. void tasklet_init(structtasklet_struct *t,  
2.           void (*func)(unsigned long), unsigned long data)  
3. {  
4.     t->next = NULL;  
5.     t->state = 0;  
6.     atomic_set(&t->count, 0);  
7.     t->func = func;  
8.     t->data = data;  
9. }