Linux 内核之中断

一、引    子    (    http://blog.csdn.net/ccjjnn19890720/article/details/7284474 )

1.中断引入？

        硬件如果要和cpu进行通信有那么几种方法？（把这个过程比作是老师分苹果的故事）   

        有程序查询法，中断，DMA，通道等。

      程序查询法就是老师每一个小孩子都去问，他们的苹果有没有吃完了，想想这也是一件比较累的事情。中断就比较智能了，就是当小孩子自己吃完了苹果，如果还想要的话就自己去想老师要。DMA好像是老师把这个权利给了一个孩子，如果有人要苹果的时候，这个时候老师就叫一个小孩子过来，说接下来的事情就交给你了，你帮我分苹果，但是还是必须要和我说一下的，但是苹果是你去分。通道好像就是老师这个职位对于分苹果已经不管了，有一个专门的一个人来管理这个事情。

        不过没有一种方法可以解决所有的问题，因为有的硬件与cpu通信数据量比较大，可以选择是DMA和通道，但是如果硬件本身是一个低速的设备，使用通道和DMA可以说是一种资源的浪费，而这个时候中断也就是最好的解决的方式。你有需要才来告诉我，而不是我(cpu)一直去询问你。这是一种从被动到主动的过程。这样cpu就不用花大量的时间周期去查询你有没有要处理的请求。这样解放了cpu，使cpu有更多的时间去处理它要做的事情。

2.中断实例

       首先，中断的过程其实很简单，比如键盘这个中断过程就是，当键盘被按下了，那么就会产生一个电信号(可以认为中断就是一个电信号)，这个信号会传到中断控制器，然后中断控制器在上报到cpu，cpu 收到这个请求的时候就会中断自己当前的事情来出来出来键盘的输入。其实这是一个很简单的过程。虽然过程很简单，但是操作系统本身要做可没有想象中的那么简单，因为很多东西都是那么容易让人混淆的。

3.中断基础

（1）中断的概念:指CPU在执行过程中，出现某些突发事件急待处理，CPU暂停执行当前程序，转去处理突发事件，处理完后CPU又返回原程序被中断的位置继续执行
（2）中断的分类:内部中断和外部中断
          内部中断:中断源来自CPU内部(软件中断指令、溢出、触发错误等)
          外部中断:中断源来自CPU外部，由外设提出请求

（3）屏蔽中断和不可屏蔽中断:
          可屏蔽中断:可以通过屏蔽字被屏蔽，屏蔽后，该中断不再得到响应
          不可屏蔽中断:不能被屏蔽

（4）向量中断和非向量中断:
          向量中断:CPU通常为不同的中断分配不同的中断号,当检测到某中断号的中断到来后,就自动跳转到与该中断号对应的地址执行
          非向量中断:多个中断共享一个入口地址。进入该入口地址后再通过软件判断中断标志来识别具体哪个是中断
           ///也就是说向量中断由软件提供中断服务程序入口地址，非向量中断由软件提供中断入口地址

        /*典型的非向量中断首先会判断中断源，然后调用不同中断源的中断处理程序*/
irq_handler()
{
...
int int_src = read_int_status();/*读硬件的中断相关寄存器*/
switch(int_src){//判断中断标志
case DEV_A:
dev_a_handler();
break;
case DEV_B:
dev_b_handler();
break;
...
default:
break;
}
...
}

二、中断的请求过程

外部设备当需要操作系统做相关的事情的时候，会产生相应的中断。设备通过相应的中断线向中断控制器发送高电平以产生中断信号，而操作系统则会从中断控制器的状态位取得那根中断线上产生的中断。而且只有在设备在对某一条中断线拥有控制权，才可以向这条中断线上发送信号。也由于现在的外设越来越多，中断线又是很宝贵的资源不可能被一一对应。因此在使用中断线前，就得对相应的中断线进行申请。无论采用共享中断方式还是独占一个中断，申请过程都是先讲所有的中断线进行扫描，得出哪些没有别占用，从其中选择一个作为该设备的IRQ。

 其次，通过中断申请函数申请相应的IRQ。

 最后，根据申请结果查看中断是否能够被执行。

中断机制的核心数据结构是 irq_desc， 它完整地描述了一条中断线 （或称为 “中断通道” ）。以下程序源码版本为linux-2.6.32.2。

其中irq_desc 结构在 include/linux/irq.h 中定义：

typedef    void (*irq_flow_handler_t)(unsigned int irq,

                      struct irq_desc *desc);

struct irq_desc {

    unsigned int      irq;    

    struct timer_rand_state *timer_rand_state;

    unsigned int            *kstat_irqs;

#ifdef CONFIG_INTR_REMAP

    struct irq_2_iommu      *irq_2_iommu;

#endif

    irq_flow_handler_t   handle_irq; /* 高层次的中断事件处理函数 */

    struct irq_chip      *chip; /* 低层次的硬件操作 */

    struct msi_desc      *msi_desc;

    void          *handler_data; /* chip 方法使用的数据*/

    void          *chip_data; /* chip 私有数据 */

    struct irqaction  *action;   /* 行为链表(action list) */

    unsigned int      status;       /* 状态 */

    unsigned int      depth;     /* 关中断次数 */

    unsigned int      wake_depth;   /* 唤醒次数 */

    unsigned int      irq_count; /* 发生的中断次数 */

    unsigned long     last_unhandled;   /*滞留时间 */

    unsigned int      irqs_unhandled;

    spinlock_t    lock; /*自选锁*/

#ifdef CONFIG_SMP

    cpumask_var_t     affinity;

    unsigned int      node;

#ifdef CONFIG_GENERIC_PENDING_IRQ

    cpumask_var_t     pending_mask;

#endif

#endif

    atomic_t      threads_active;

    wait_queue_head_t   wait_for_threads;

#ifdef CONFIG_PROC_FS

    struct proc_dir_entry    *dir; /* 在 proc 文件系统中的目录 */

#endif

    const char    *name;/*名称*/

} ____cacheline_internodealigned_in_smp;

 

I、Linux中断的申请与释放：在<linux/interrupt.h>, 实现中断申请接口:

request_irq(unsigned int irq, irq_handler_t handler, unsigned long flags,const char *name, void *dev);

函数参数说明

unsigned int irq：所要申请的硬件中断号

irq_handler_t handler：中断服务程序的入口地址，中断发生时，系统调用handler这个函数。irq_handler_t为自定义类型，其原型为：

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

而irqreturn_t的原型为：typedef enum irqreturn irqreturn_t;

enum irqreturn {

    IRQ_NONE,/*此设备没有产生中断*/

    IRQ_HANDLED,/*中断被处理*/

    IRQ_WAKE_THREAD,/*唤醒中断*/

};

在枚举类型irqreturn定义在include/linux/irqreturn.h文件中。

 

unsigned long flags：中断处理的属性，与中断管理有关的位掩码选项，有一下几组值：

#define IRQF_DISABLED       0x00000020    /*中断禁止*/

#define IRQF_SAMPLE_RANDOM  0x00000040    /*供系统产生随机数使用*/

#define IRQF_SHARED      0x00000080 /*在设备之间可共享*/

#define IRQF_PROBE_SHARED   0x00000100/*探测共享中断*/

#define IRQF_TIMER       0x00000200/*专用于时钟中断*/

#define IRQF_PERCPU      0x00000400/*每CPU周期执行中断*/

#define IRQF_NOBALANCING 0x00000800/*复位中断*/

#define IRQF_IRQPOLL     0x00001000/*共享中断中根据注册时间判断*/

#define IRQF_ONESHOT     0x00002000/*硬件中断处理完后触发*/

#define IRQF_TRIGGER_NONE   0x00000000/*无触发中断*/

#define IRQF_TRIGGER_RISING 0x00000001/*指定中断触发类型：上升沿有效*/

#define IRQF_TRIGGER_FALLING 0x00000002/*中断触发类型：下降沿有效*/

#define IRQF_TRIGGER_HIGH   0x00000004/*指定中断触发类型：高电平有效*/

#define IRQF_TRIGGER_LOW 0x00000008/*指定中断触发类型：低电平有效*/

#define IRQF_TRIGGER_MASK   (IRQF_TRIGGER_HIGH | IRQF_TRIGGER_LOW | \

               IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING)

#define IRQF_TRIGGER_PROBE  0x00000010/*触发式检测中断*/

 

const char *dev_name：设备描述，表示那一个设备在使用这个中断。

 

void *dev_id：用作共享中断线的指针.。一般设置为这个设备的设备结构体或者NULL。它是一个独特的标识, 用在当释放中断线时以及可能还被驱动用来指向它自己的私有数据区，来标识哪个设备在中断 。这个参数在真正的驱动程序中一般是指向设备数据结构的指针.在调用中断处理程序的时候它就会传递给中断处理程序的void *dev_id。如果中断没有被共享, dev_id 可以设置为 NULL。

II、释放IRQ

void free_irq(unsigned int irq, void *dev_id);

III、中断线共享的数据结构

   struct irqaction {

    irq_handler_t handler; /* 具体的中断处理程序 */

    unsigned long flags;/*中断处理属性*/

    const char *name; /* 名称，会显示在/proc/interreupts 中 */

    void *dev_id; /* 设备ID，用于区分共享一条中断线的多个处理程序 */

    struct irqaction *next; /* 指向下一个irq_action 结构 */

    int irq;  /* 中断通道号 */

    struct proc_dir_entry *dir; /* 指向proc/irq/NN/name 的入口*/

    irq_handler_t thread_fn;/*线程中断处理函数*/

    struct task_struct *thread;/*线程中断指针*/

    unsigned long thread_flags;/*与线程有关的中断标记属性*/

};

thread_flags参见枚举型

enum {

    IRQTF_RUNTHREAD,/*线程中断处理*/

    IRQTF_DIED,/*线程中断死亡*/

    IRQTF_WARNED,/*警告信息*/

    IRQTF_AFFINITY,/*调整线程中断的关系*/

};

多个中断处理程序可以共享同一条中断线，irqaction 结构中的 next 成员用来把共享同一条中断线的所有中断处理程序组成一个单向链表,dev_id 成员用于区分各个中断处理程序。

三．中断的处理过程1（http://blog.chinaunix.net/uid-26772535-id-3222508.html）

1、最简单的中断机制

最简单的中断机制就是像芯片手册上讲的那样，在中断向量表中填入跳转到对应处理函数的指令，然后在处理函数中实现需要的功能。类似下图：

这种方式在原来的单片机课程中常常用到，一些简单的单片机系统也是这样用。

它的好处很明显，简单，直接。

 

2、linux中断处理的下半部概念引入

中断处理函数所作的第一件事情是什么？答案是屏蔽中断（或者是什么都不做，因为常常是如果不清除IF位，就等于屏蔽中断了），当然只屏蔽同一种中断。之所以要屏蔽中断，是因为新的中断会再次调用中断处理函数，导致原来中断处理现场的破坏。即，破坏了 interrupt context。

随着系统的不断复杂，中断处理函数要做的事情也越来越多，多到都来不及接收新的中断了。于是发生了中断丢失，这显然不行，于是产生了新的机制：分离中断接收与中断处理过程。中断接收在屏蔽中断的情况下完成；中断处理在时能中断的情况下完成，这部分被称为中断下半部。

从上图中看，只看int0的处理。Func0为中断接收函数。中断只能简单的触发func0，而func0则能做更多的事情，它与funcA之间可以使用队列等缓存机制。当又有中断发生时，func0被触发，然后发送一个中断请求到缓存队列，然后让funcA去处理。

由于func0做的事情是很简单的，所以不会影响int0的再次接收。而且在func0返回时就会使能int0，因此funcA执行时间再长也不会影响int0的接收。

【注意1-上半部分与下班部分】:Linux中断分为两个半部：上半部（tophalf）和下半部(bottom half)。

上半部的功能是"登记中断"，当一个中断发生时，它进行相应地硬件读写后就把中断例程的下半部挂到该设备的下半部执行队列中去。因此，上半部执行的速度就会很快，可以服务更多的中断请求。但是，仅有"登记中断"是远远不够的，因为中断的事件可能很复杂。

 因此,Linux引入了一个下半部，来完成中断事件的绝大多数使命。

 下半部和上半部最大的不同是下半部是可中断的，而上半部是不可中断的，下半部几乎做了中断处理程序所有的事情，而且可以被新的中断打断！下半部则相对来说并不是非常紧急的，通常还是比较耗时的，因此由系统自行安排运行时机，不在中断服务上下文中执行。

【注意2-查看中断号】:linux 中断号的查看可以使用下面的命令： cat  /proc/interrupts”。

【注意3-下半部的实现机制比较1】:

 (1)在Linux2.6的内核中存在三种不同形式的下半部实现机制：软中断， tasklet  和 工作队列。

 简单地说，一般的驱动程序的编写者需要做两个选择。 首先，你是不是需要一个可调度的实体来执行需要推后完成的工作――从根本上来说，有休眠的需要吗？

=====>>>>要是有，工作队列就是你的惟一选择。

=====>>>>否则最好用tasklet。要是必须专注于性能的提高，那么就考虑softirq。

                                          

   软中断和tasklet都是运行在中断上下文中，它们与任一进程无关，没有支持的进程完成重新调度。所以软中断和tasklet不能睡眠、不能阻塞，它们的代码中不能含有导致睡眠的动作，如减少信号量、从用户空间拷贝数据或手工分配内存等。也正是由于它们运行在中断上下文中，所以它们在同一个CPU上的执行是串行的，这样就不利于实时多媒体任务的优先处理。

      而工作队列用于：如果推后执行的任务需要睡眠，那么就选择工作队列。另外，如果需要用一个可以重新调度的实体来执行你的下半部处理，也应该使用工作队列。它是唯一能在进程上下文运行的下半部实现的机制，也只有它才可以睡眠。这意味着在需要获得大量的内存时、在需要获取信号量时，在需要执行阻塞式的I/O操作时，它都会非常有用。

(2)下面将比较三种机制的差别与联系。
        软中断：

   软中断支持SMP，同一个softirq可以在不同的CPU上同时运行，softirq必须是可重入的。软中断是在编译期间静态分配的，它不像tasklet那样能被动态的注册或去除。kernel/softirq.c中定义了一个包含32个softirq_action结构体的数组。每个被注册的软中断都占据该数组的一项。因此最多可能有32个软中断。2.6版本的内核中定义了六个软中断：HI_SOFTIRQ、TIMER_SOFTIRQ、NET_TX_SOFTIRQ、NET_RX_SOFTIRQ、 SCSI_SOFTIRQ、TASKLET_SOFTIRQ。
        一般情况下，在硬件中断处理程序后都会试图调用do_softirq（）函数，每个CPU都是通过执行这个函数来执行软中断服务的。由于软中断不能进入硬中断部分，且同一个CPU上软中断的执行是串行的，即不允许嵌套，因此，do_softirq()函数一开始就检查当前CPU是否已经正出在中断服务中，如果是则 do_softirq()函数立即返回。这是由do_softirq（）函数中的 if (in_interrupt()) return; 保证的。

 1、软中断是在编译期间静态分配的。
         2、最多可以有32个软中断。
         3、软中断不会抢占另外一个软中断，唯一可以抢占软中断的是中断处理程序。
         4、可以并发运行在多个CPU上（即使同一类型的也可以）。所以软中断必须设计为可重入的函数（允许多个CPU同时操作），
            因此也需要使用自旋锁来保护其数据结构。
         5、目前只有两个子系直接使用软中断：网络和SCSI。
         6、执行时间有：从硬件中断代码返回时、在ksoftirqd内核线程中和某些显示检查并执行软中断的代码中。

 tasklet：

 引入tasklet，最主要的是考虑支持SMP，提高SMP多个cpu的利用率；不同的tasklet可以在不同的cpu上运行。tasklet可以理解为softirq的派生，所以它的调度时机和软中断一样。对于内核中需要延迟执行的多数任务都可以用tasklet来完成，由于同类tasklet本身已经进行了同步保护，所以使用tasklet比软中断要简单的多，而且效率也不错。 tasklet把任务延迟到安全时间执行的一种方式，在中断期间运行，即使被调度多次，tasklet也只运行一次，不过tasklet可以在SMP系统上和其他不同的tasklet并行运行。在SMP系统上，tasklet还被确保在第一个调度它的CPU上运行，因为这样可以提供更好的高速缓存行为，从而提高性能。 

    与一般的软中断不同，某一段tasklet代码在某个时刻只能在一个CPU上运行，但不同的tasklet代码在同一时刻可以在多个CPU上并发地执行。 Kernel/softirq.c中用tasklet_trylock()宏试图对当前要执行的tasklet（由指针t所指向）进行加锁，如果加锁成功（当前没有任何其他CPU正在执行这个tasklet），则用原子读函数atomic_read()进一步判断count成员的值。如果count为0，说明这个tasklet是允许执行的。如果tasklet_trylock()宏加锁不成功，或者因为当前tasklet的count值非0而不允许执行时，我们必须将这个tasklet重新放回到当前CPU的tasklet队列中，以留待这个CPU下次服务软中断向量TASKLET_SOFTIRQ时再执行。为此进行这样几步操作：

（1）先关 CPU中断，以保证下面操作的原子性。

（2）把这个tasklet重新放回到当前CPU的tasklet队列的首部；

（3）调用 __cpu_raise_softirq()函数在当前CPU上再触发一次软中断请求TASKLET_SOFTIRQ；

（4）开中断。
       软中断和tasklet都是运行在中断上下文中，它们与任一进程无关，没有支持的进程完成重新调度。所以软中断和tasklet不能睡眠、不能阻塞，它们的代码中不能含有导致睡眠的动作，如减少信号量、从用户空间拷贝数据或手工分配内存等。也正是由于它们运行在中断上下文中，所以它们在同一个CPU上的执行是串行的，这样就不利于实时多媒体任务的优先处理。

  引入tasklet，最主要的是考虑支持SMP，提高SMP多个cpu的利用率；两个相同的tasklet决不会同时执行。tasklet可以理解为softirq的派生，所以它的调度时机和软中断一样。对于内核中需要延迟执行的多数任务都可以用tasklet来完成，由于同类tasklet本身已经进行了同步保护，所以使用tasklet比软中断要简单的多，而且效率也不错。tasklet把任务延迟到安全时间执行的一种方式，在中断期间运行，即使被调度多次，tasklet也只运行一次，不过tasklet可以在SMP系统上和其他不同的tasklet并行运行。在SMP系统上，tasklet还被确保在第一个调度它的CPU上运行，因为这样可以提供更好的高速缓存行为，从而提高性能。

       tasklet的特性：.不允许两个两个相同类型的tasklet同时执行，即使在不同的处理器上。

     1、tasklet是使用两类软中断实现的：HI_SOFTIRQ和TASKLET_SOFTIRQ。
          2、可以动态增加减少，没有数量限制。
          3、同一类tasklet不能并发执行。
          4、不同类型可以并发执行。
          5、大部分情况使用tasklet。

 工作队列：

        如果推后执行的任务需要睡眠，那么就选择工作队列。另外，如果需要用一个可以重新调度的实体来执行你的下半部处理，也应该使用工作队列。它是唯一能在进程上下文运行的下半部实现的机制，也只有它才可以睡眠。这意味着在需要获得大量的内存时、在需要获取信号量时，在需要执行阻塞式的I/O操作时，它都会非常有用。work queue造成的开销最大，因为它要涉及到内核线程甚至是上下文切换。这并不是说work queue的低效，但每秒钟有数千次中断，就像网络子系统时常经历的那样，那么采用其他的机制可能更合适一些。 尽管如此，针对大部分情况工作队列都能提供足够的支持。

      工作队列特性：
      1).工作队列会在进程上下文中执行！
      2).可以阻塞。(前两种机制是不可以阻塞的)
      3).可以被重新调度。(前两种只可以被中断处理程序打断)
      4).使用工作队列的两种形式：
             1>缺省工作者线程(works threads)
             2>自建的工作者线程
      5).在工作队列和内核其他部分之间使用锁机制就像在其他的进程上下文一样。
      6).默认允许响应中断。
      7).默认不持有任何锁。

     1、由内核线程去执行，换句话说总在进程上下文执行。
          2、可以睡眠，阻塞。

【注意4-下半部的实现机制比较2】:

tasklet与workqueue的区别和不同应用环境总结2

  什么情况下使用工作队列，什么情况下使用tasklet。

  （1）如果推后执行的任务需要睡眠，那么就选择工作队列。另外，如果需要用一个可以重新调度的实体来执行你的下半部处理，也应该使用工作队列。它是唯一能在进程上下文运行的下半部实现的机制，也只有它才可以睡眠。这意味着在需要获得大量的内存时、在需要获取信号量时，在需要执行阻塞式的I/O操作时，它都会非常有用。

  （2）如果推后执行的任务不需要睡眠，那么就选择tasklet。如果不需要用一个内核线程来推后执行工作，那么就考虑使用tasklet。

【注意5-下半部使用方式】

           Request_irq 挂的中断函数要尽量简单，只做必须在屏蔽中断情况下要做的事情。中断的其他部分都在下半部中完成。

           软中断的使用原则很简单，永远不用。它甚至都不算是一种正是的中断处理机制，而只是tasklet的实现基础。

工作队列也要少用，如果不是必须要用到线程才能用的某些机制，就不要使用工作队列。其实对于中断来说，只是对中断进行简单的处理，大部分工作是在驱动程序中完成的。所以有什么必要非使用工作队列呢？

除了上述情况，就要使用tasklet。

           即使是下半部，也只是作必须在中断中要做的事情，如保存数据等，其他都交给驱动程序去做。

3、Linux实现下半部的机制--(1)软中断

下面看看linux中断处理。作为一个操作系统显然不能任由每个中断都各自为政，统一管理是必须的。

我们不可中断部分的共同部分放在函数do_IRQ中，需要添加中断处理函数时，通过request_irq实现。下半部放在do_softirq中，也就是软中断，通过open_softirq添加对应的处理函数。

 

4、Linux实现下半部的机制--(2)tasklet

(Tasklet作为一种新机制，显然可以承担更多的优点。正好这时候SMP越来越火了，因此又在tasklet中加入了SMP机制，保证同种中断只能在一个cpu上执行。在软中断时代，显然没有这种考虑。因此同一种中断可以在两个cpu上同时执行，很可能造成冲突.)

旧事物跟不上历史的发展时，总会有新事物出现。

随着中断数的不停增加，软中断不够用了，于是下半部又做了进化。

软中断用轮询的方式处理。假如正好是最后一种中断，则必须循环完所有的中断类型，才能最终执行对应的处理函数。显然当年开发人员为了保证轮询的效率，于是限制中断个数为32个。

为了提高中断处理数量，顺道改进处理效率，于是产生了tasklet机制。

Tasklet采用无差别的队列机制，有中断时才执行，免去了循环查表之苦。

总结下tasklet的优点：

（1）无类型数量限制；

（2）效率高，无需循环查表；

（3）支持SMP机制；

 

5、Linux实现下半部的机制--(3)工作队列

 前面的机制不论如何折腾，有一点是不会变的。它们都在中断上下文中。什么意思？说明它们不可挂起。而且由于是串行执行，因此只要有一个处理时间较长，则会导致其他中断响应的延迟。为了完成这些不可能完成的任务，于是出现了工作队列。工作队列说白了就是一组内核线程，作为中断守护线程来使用。多个中断可以放在一个线程中，也可以每个中断分配一个线程。

工作队列对线程作了封装，使用起来更方便。

因为工作队列是线程，所以我们可以使用所有可以在线程中使用的方法。

Tasklet其实也不一定是在中断上下文中执行，它也有可能在线程中执行。

假如中断数量很多，而且这些中断都是自启动型的（中断处理函数会导致新的中断产生），则有可能cpu一直在这里执行中断处理函数，会导致用户进程永远得不到调度时间。

为了避免这种情况，linux发现中断数量过多时，会把多余的中断处理放到一个单独的线程中去做，就是ksoftirqd线程。这样又保证了中断不多时的响应速度，又保证了中断过多时不会把用户进程饿死。

问题是我们不能保证我们的tasklet或软中断处理函数一定会在线程中执行，所以还是不能使用进程才能用的一些方法，如放弃调度、长延时等。 

三．中断的处理过程2--实现实例（http://blog.csdn.net/dragon101788/article/details/10238415）

1、中断处理的tasklet（小任务）机制

中断服务程序一般都是在中断请求关闭的条件下执行的,以避免嵌套而使中断控制复杂化。但是，中断是一个随机事件，它随时会到来，如果关中断的时间太长，CPU就不能及时响应其他的中断请求，从而造成中断的丢失。因此，Linux内核的目标就是尽可能快的处理完中断请求，尽其所能把更多的处理向后推迟。例如，假设一个数据块已经达到了网线，当中断控制器接受到这个中断请求信号时，Linux内核只是简单地标志数据到来了，然后让处理器恢复到它以前运行的状态，其余的处理稍后再进行（如把数据移入一个缓冲区，接受数据的进程就可以在缓冲区找到数据）。因此，内核把中断处理分为两部分：上半部（tophalf）和下半部（bottomhalf），上半部（就是中断服务程序）内核立即执行，而下半部（就是一些内核函数）留着稍后处理，

首先，一个快速的“上半部”来处理硬件发出的请求，它必须在一个新的中断产生之前终止。通常，除了在设备和一些内存缓冲区（如果你的设备用到了DMA，就不止这些）之间移动或传送数据，确定硬件是否处于健全的状态之外，这一部分做的工作很少。

下半部运行时是允许中断请求的，而上半部运行时是关中断的，这是二者之间的主要区别。

但是，内核到底什时候执行下半部，以何种方式组织下半部？这就是我们要讨论的下半部实现机制，这种机制在内核的演变过程中不断得到改进，在以前的内核中，这个机制叫做bottomhalf(简称bh)，在2.4以后的版本中有了新的发展和改进，改进的目标使下半部可以在多处理机上并行执行，并有助于驱动程序的开发者进行驱动程序的开发。下面主要介绍常用的小任务(Tasklet)机制及2.6内核中的工作队列机制。

小任务机制

这里的小任务是指对要推迟执行的函数进行组织的一种机制。其数据结构为tasklet_struct，每个结构代表一个独立的小任务，其定义如下：

<span style="font-family:SimSun;font-size:18px;">struct tasklet_struct {struct tasklet_struct *next; /*指向链表中的下一个结构*/unsignedlong state; /* 小任务的状态*/atomic_tcount; /* 引用计数器*/void(*func) (unsigned long); /* 要调用的函数*/unsignedlong data; /* 传递给函数的参数*/}；</span>

结构中的func域就是下半部中要推迟执行的函数，data是它唯一的参数。
State域的取值为TASKLET_STATE_SCHED或TASKLET_STATE_RUN。TASKLET_STATE_SCHED表示小任务已被调度，正准备投入运行，TASKLET_STATE_RUN表示小任务正在运行。         TASKLET_STATE_RUN只有在多处理器系统上才使用，单处理器系统什么时候都清楚一个小任务是不是正在运行（它要么就是当前正在执行的代码，要么不是）。
Count域是小任务的引用计数器。如果它不为0，则小任务被禁止，不允许执行；只有当它为零，小任务才被激活，并且在被设置为挂起时，小任务才能够执行。
1. 声明和使用小任务大多数情况下，为了控制一个寻常的硬件设备，小任务机制是实现下半部的最佳选择。小任务可以动态创建，使用方便，执行起来也比较快。
我们既可以静态地创建小任务，也可以动态地创建它。选择那种方式取决于到底是想要对小任务进行直接引用还是一个间接引用。如果准备静态地创建一个小任务（也就是对它直接引用），使用下面两个宏中的一个：
DECLARE_TASKLET(name,func, data)
DECLARE_TASKLET_DISABLED(name,func, data)
这两个宏都能根据给定的名字静态地创建一个tasklet_struct结构。当该小任务被调度以后，给定的函数func会被执行，它的参数由data给出。这两个宏之间的区别在于引用计数器的初始值设置不同。第一个宏把创建的小任务的引用计数器设置为0，因此，该小任务处于激活状态。另一个把引用计数器设置为1，所以该小任务处于禁止状态。例如：
DECLARE_TASKLET(my_tasklet,my_tasklet_handler, dev);
这行代码其实等价于
structtasklet_struct my_tasklet = { NULL, 0, ATOMIC_INIT(0),
tasklet_handler,dev};
这样就创建了一个名为my_tasklet的小任务，其处理程序为tasklet_handler，并且已被激活。当处理程序被调用的时候，dev就会被传递给它。
2. 编写自己的小任务处理程序小任务处理程序必须符合如下的函数类型：
voidtasklet_handler(unsigned long data)
由于小任务不能睡眠，因此不能在小任务中使用信号量或者其它产生阻塞的函数。但是小任务运行时可以响应中断。
3. 调度自己的小任务通过调用tasklet_schedule()函数并传递给它相应的tasklt_struct指针，该小任务就会被调度以便适当的时候执行：
tasklet_schedule(&my_tasklet); /*把my_tasklet标记为挂起 */
在小任务被调度以后，只要有机会它就会尽可能早的运行。在它还没有得到运行机会之前，如果一个相同的小任务又被调度了，那么它仍然只会运行一次。
可以调用tasklet_disable()函数来禁止某个指定的小任务。如果该小任务当前正在执行，这个函数会等到它执行完毕再返回。调用tasklet_enable()函数可以激活一个小任务，如果希望把以DECLARE_TASKLET_DISABLED（）创建的小任务激活，也得调用这个函数，如：
tasklet_disable(&my_tasklet); /*小任务现在被禁止,这个小任务不能运行*/
tasklet_enable(&my_tasklet); /* 小任务现在被激活*/
也可以调用tasklet_kill()函数从挂起的队列中去掉一个小任务。该函数的参数是一个指向某个小任务的tasklet_struct的长指针。在小任务重新调度它自身的时候，从挂起的队列中移去已调度的小任务会很有用。这个函数首先等待该小任务执行完毕，然后再将它移去。
4.tasklet的简单用法
下面是tasklet的一个简单应用,以模块的形成加载。

<span style="font-family:SimSun;font-size:18px;">#include <linux/module.h>#include<linux/init.h>#include<linux/fs.h>#include<linux/kdev_t.h>#include <linux/cdev.h>#include <linux/kernel.h>#include<linux/interrupt.h>static struct t asklet_struct my_tasklet;static void tasklet_handler (unsigned longd ata){printk(KERN_ALERT,"tasklet_handler is running./n");}staticint __init test_init(void){tasklet_init(&my_tasklet,tasklet_handler,0);tasklet_schedule(&my_tasklet);return0;}static void __exit test_exit(void){tasklet_kill(&tasklet);printk(KERN_ALERT,"test_exit is running./n");}MODULE_LICENSE("GPL");module_init(test_init);module_exit(test_exit);</span>

从这个例子可以看出，所谓的小任务机制是为下半部函数的执行提供了一种执行机制，也就是说，推迟处理的事情是由tasklet_handler实现，何时执行，经由小任务机制封装后交给内核去处理。

二、中断处理的工作队列机制

工作队列（work queue）是另外一种将工作推后执行的形式，它和前面讨论的tasklet有所不同。工作队列可以把工作推后，交由一个内核线程去执行，也就是说，这个下半部分可以在进程上下文中执行。这样，通过工作队列执行的代码能占尽进程上下文的所有优势。最重要的就是工作队列允许被重新调度甚至是睡眠。

那么，什么情况下使用工作队列，什么情况下使用tasklet。如果推后执行的任务需要睡眠，那么就选择工作队列。如果推后执行的任务不需要睡眠，那么就选择tasklet。另外，如果需要用一个可以重新调度的实体来执行你的下半部处理，也应该使用工作队列。它是唯一能在进程上下文运行的下半部实现的机制，也只有它才可以睡眠。这意味着在需要获得大量的内存时、在需要获取信号量时，在需要执行阻塞式的I/O操作时，它都会非常有用。如果不需要用一个内核线程来推后执行工作，那么就考虑使用tasklet。

1.工作、工作队列和工作者线程

      如前所述，我们把推后执行的任务叫做工作（work），描述它的数据结构为work_struct，这些工作以队列结构组织成工作队列（workqueue），其数据结构为workqueue_struct，而工作线程就是负责执行工作队列中的工作。系统默认的工作者线程为events,自己也可以创建自己的工作者线程。

2.表示工作的数据结构

工作用<linux/workqueue.h>中定义的work_struct结构表示：

struct work_struct{unsigned long pending; /* 这个工作正在等待处理吗？*/struct list_head entry; /* 连接所有工作的链表 */void (*func) (void *); /* 要执行的函数 */void *data; /* 传递给函数的参数 */void *wq_data; /* 内部使用 */struct timer_list timer; /* 延迟的工作队列所用到的定时器 */};

这些结构被连接成链表。当一个工作者线程被唤醒时，它会执行它的链表上的所有工作。工作被执行完毕，它就将相应的work_struct对象从链表上移去。当链表上不再有对象的时候，它就会继续休眠。

3. 创建推后的工作

要使用工作队列，首先要做的是创建一些需要推后完成的工作。可以通过DECLARE_WORK在编译时静态地建该结构：

DECLARE_WORK(name, void (*func) (void *), void *data);

这样就会静态地创建一个名为name，待执行函数为func，参数为data的work_struct结构。

同样，也可以在运行时通过指针创建一个工作：

INIT_WORK(struct work_struct *work, woid(*func) (void *), void *data);

这会动态地初始化一个由work指向的工作。

4. 工作队列中待执行的函数

工作队列待执行的函数原型是：

void work_handler(void *data)

这个函数会由一个工作者线程执行，因此，函数会运行在进程上下文中。默认情况下，允许响应中断，并且不持有任何锁。如果需要，函数可以睡眠。需要注意的是，尽管该函数运行在进程上下文中，但它不能访问用户空间，因为内核线程在用户空间没有相关的内存映射。通常在系统调用发生时，内核会代表用户空间的进程运行，此时它才能访问用户空间，也只有在此时它才会映射用户空间的内存。

5. 对工作进行调度

现在工作已经被创建，我们可以调度它了。想要把给定工作的待处理函数提交给缺省的events工作线程，只需调用

schedule_work(&work)；

work马上就会被调度，一旦其所在的处理器上的工作者线程被唤醒，它就会被执行。

有时候并不希望工作马上就被执行，而是希望它经过一段延迟以后再执行。在这种情况下，可以调度它在指定的时间执行：

schedule_delayed_work(&work, delay);

这时，&work指向的work_struct直到delay指定的时钟节拍用完以后才会执行。

6. 工作队列的简单应用

#include<linux/module.h>#include<linux/init.h>#include<linux/workqueue.h>staticstruct workqueue_struct *queue =NULL;staticstruct work_struct work;staticvoid work_handler(struct work_struct*data){printk(KERN_ALERT"work handler function./n");}staticint __init test_init(void){queue= create_singlethread_workqueue("helloworld"); /*创建一个单线程的工作队列*/if(!queue)goto err;INIT_WORK(&work, work_handler);schedule_work(&work);/*schedule_work是添加到系统的events workqueue, 要添加到自己的workqueue, 应该使用queue_work, 故此处有误*/return 0;err:return-1;}staticvoid __exit test_exit(void){destroy_workqueue(queue);}MODULE_LICENSE("GPL");module_init(test_init);module_exit(test_exit);