linux 中断

 

摘自：http://www.kerneltravel.net/journal/viii/01.htm

计算机系统实现中断机制是非常复杂的一件工作，再怎么说人都是高度智能化的生物，而计算机作为一个铁疙瘩，没有程序的教导就一事无成。而处理一个中断过程，它受到的限制和需要学习的东西太多了。

首先，计算机能够接收的外部信号形式非常有限。PC给所有的外部刺激只留了一种输入方式——特定格式的电信号，并对这种信号的格式、接入方法、响应方法、处理步骤都做了规约，这种信号就是中断或中断信号，而这一整套机制就是中断机制。
      其次，计算机不懂得如何应对信号。没有程序，它就纹丝不动。因此，必须有机制保证外部中断信号到来后，有正确的程序在正确的时候被执行。
      还有，计算机不懂得如何保持工作的持续性。

那么，通用的计算机系统是如何解决这些问题的呢？它是靠硬件和软件配合来协同实现中断处理的全过程的。我们将通过Intel X86架构的实现来介绍这一过程。

CPU执行完一条指令后，下一条指令的逻辑地址存放在cs和eip这对寄存器中。在执行新指令前，控制单元会检查在执行前一条指令的过程中是否有中断或异常发生。如果有，控制单元就会抛下指令，进入下面的流程：
1.       确定与中断或异常关联的向量i (0<= i <=255)
2.       寻找向量对应的处理程序
3.       保存当前的“工作现场”，执行中断或异常的处理程序
4.       处理程序执行完毕后，把控制权交还给控制单元
5.       控制单元恢复现场，返回继续执行原程序

让我们深入这个流程，看看都有什么问题需要面对。

1、异常是什么概念？

在处理器执行到由于编程失误而导致的错误指令（例如除数是0）的时候，或者在执行期间出现特殊情况（例如缺页），需要靠操作系统来处理的时候，处理器就会产生一个异常。对大部分处理器体系结构来说，处理异常和处理中断的方式基本是相同的，x86架构的CPU也是如此。异常与中断还是有些区别，异常的产生必须考虑与处理器时钟的同步。实际上，异常往往被称为同步中断。 

2、中断向量是什么？

中断向量代表的是中断源——从某种程度上讲，可以看作是中断或异常的类型。中断和异常的种类很多，比如说被0除是一种异常，缺页又是一种异常，网卡会产生中断，声卡也会产生中断，CPU如何区分它们呢？中断向量的概念就是由此引出的，其实它就是一个被送通往CPU数据线的一个整数。CPU给每个IRQ分配了一个类型号，通过这个整数CPU来识别不同类型的中断。这里可能很多朋友会寻问为什么还要弄个中断向量这么麻烦的东东？为什么不直接用IRQ0~IRQ15就完了？比如就让IRQ0为0，IRQ1为1……，这不是要简单得多么？其实这里体现了模块化设计规则，及节约规则。

首先我们先谈谈节约规则，所谓节约规则就是所使用的信号线数越少越好，这样如果每个IRQ都独立使用一根数据线，如IRQ0用0号线，IRQ1用1号线……这样，16个IRQ就会用16根线，这显然是一种浪费。那么也许马上就有朋友会说：那么只用4根线不就行了吗？（2^4=16）。

这个问题，体现了模块设计规则。我们在前面就说过中断有很多类，可能是外部硬件触发，也可能是由软件触发，然而对于CPU来说中断就是中断，只有一种，CPU不用管它到底是由外部硬件触发的还是由运行的软件本身触发的，因为对于CPU来说，中断处理的过程都是一样的：中断现行程序，转到中断服务程序处执行，回到被中断的程序继续执行。CPU总共可以处理256种中断，而并不知道，也不应当让CPU知道这是硬件来的中断还是软件来的中断，这样，就可以使CPU的设计独立于中断控制器的设计，这样CPU所需完成的工作就很单纯了。CPU对于其它的模块只提供了一种接口，这就是256个中断处理向量，也称为中断号。由这些中断控制器自行去使用这256个中断号中的一个与CPU进行交互，比如，硬件中断可以使用前128个号，软件中断使用后128个号，也可以软件中断使用前128个号，硬件中断使用后128个号，这与CPU完全无关了，当你需要处理的时候，只需告诉CPU你用的是哪个中断号就行，而不需告诉CPU你是来自哪儿的中断。这样也方便了以后的扩充，比如现在机器里又加了一片8259芯片，那么这个芯片就可以使用空闲的中断号，看哪一个空闲就使用哪一个，而不是必须要使用第0号，或第1号中断号了。其实这相当于一种映射机制，把IRQ信号映射到不同的中断号上，IRQ的排列或说编号是固定的，但通过改变映射机制，就可以让IRQ映射到不同的中断号，也可以说调用不同的中断服务程序。 

3、什么是中断服务程序？

在响应一个特定中断的时候，内核会执行一个函数，该函数叫做中断处理程序（interrupt handler）或中断服务程序（interrupt service routine(ISR)）。产生中断的每个设备都有相应的中断处理程序。例如，由一个函数专门处理来自系统时钟的中断，而另外一个函数专门处理由键盘产生的中断。

一般来说，中断服务程序要负责与硬件进行交互，告诉该设备中断已被接收。此外，还需要完成其他相关工作。比如说网络设备的中断服务程序除了要对硬件应答，还要把来自硬件的网络数据包拷贝到内存，对其进行处理后再交给合适的协议栈或应用程序。每个中断服务程序根据其要完成的任务，复杂程度各不相同。

一般来说，一个设备的中断服务程序是它的设备驱动程序（device driver）的一部分——设备驱动程序是用于对设备进行管理的内核代码。

 

4、隔离变化

不知道您有没有意识到，中断处理前面这部分的设计是何等的简单优美。人是高度智能化的，能够对遇到的各种意外情况做有针对性的处理，计算机相比就差距甚远了，它只能根据预定的程序进行操作。对于计算机来说，硬件支持的，只能是中断这种电信号传播的方式和CPU对这种信号的接收方法，而具体如何处理这个中断，必须得靠操作系统实现。操作系统支持所有事先能够预料到的中断信号，理论上都不存在太大的挑战，但在操作系统安装到计算机设备上以后，肯定会时常有新的外围设备被加入系统，这可能会带来安装系统时根本无法预料的“意外”中断。如何支持这种扩展，是整个系统必须面对的。

而硬件和软件在这里的协作，给我们带来了完美的答案。当新的设备引入新类型的中断时，CPU和操作系统不用关注如何处理它。CPU只负责接收中断信号，并引用中断服务程序；而操作系统提供默认的中断服务——一般来说就是不理会这个信号，返回就可以了——并负责提供接口，让用户通过该接口注册根据设备具体功能而编制的中断服务程序。如果用户注册了对应于一个中断的服务程序，那么CPU就会在该中断到来时调用用户注册的服务程序。这样，在中断来临时系统需要如何操作硬件、如何实现硬件功能这部分工作就完全独立于CPU架构和操作系统的设计了。

而当你需要加入新设备的时候，只需要告诉操作系统该设备占用的中断号、按照操作系统要求的接口格式撰写中断服务程序，用操作系统提供的函数注册该服务程序，设备的中断就被系统支持了。

中断和对中断的处理被解除了耦合。这样，无论是你在需要加入新的中断时，还是在你需要改变现有中断的服务程序时、又或是取消对某个中断支持的时候，CPU架构和操作系统都无需作改变。

 

5、保存当前工作“现场”

在中断处理完毕后，计算机一般来说还要回头处理原先手头正做的工作。这给中断的概念带来些额外的“内涵”。注一“回头”不是指从头再来重新做，而是要接着刚才的进度继续做。这就需要在处理中断信号之前保留工作“现场”。“现场”这个词比较晦涩，其实就是指一个信息集，它能反映某个时间点上任务的状态，并能保证按照这些信息就能恢复任务到该状态，继续执行下去。再直白一点，现场不过就是一组寄存器值。而如何保护现场和恢复场景是中断机制需要考虑的重点之一。
每个中断处理都要经历这个保存和恢复过程，我们可以抽象出其中的步骤：
    a.         保存现场
       b.         执行具体的中断服务程序
       c.         从中断服务返回
       d.         恢复现场

上面说过了，“现场”看似在不断变化，没有哪个瞬间相同。但实际上组成现场的要素却不会有任何改变。也就是说，只要我们保存了相关的寄存器状态，现场就能保存下来。而恢复“现场”就是重新载入这些寄存器。换句话说，对于任何一个中断，保护现场和恢复现场所做的都是完全相同的操作。

既然操作相同，实现操作的过程和代码就相同。减少代码的冗余是模块化设计的基本准则，实在没有道理让所有的中断服务程序都重复实现这样的功能，应该将它作为一种基本的结构由底层的操作系统或硬件完成。而对中断的处理过程需要迅速完成，因此，Intel CPU的控制器就承担了这个任务，非但如此，上面的所有步骤次序都被固化下来，由控制器驱动完成。保存现场和恢复现场都由硬件自动完成，大大减轻了操作系统和设备驱动程序的负担。

 

6、硬件对中断支持的细节

下面的部分，本来应该介绍8259、中断控制器编程、中断描述符表等内容，可是我看到了潇寒写的“保护模式下的8259A芯片编程及中断处理探究”（见参考资料1），前人之述备矣，读者直接读它好了。 

Linux对中断的支持

在Linux中，中断处理程序看起来就是普普通通的C函数。只不过这些函数必须按照特定的类型声明，以便内核能够以标准的方式传递处理程序的信息，在其他方面，它们与一般的函数看起来别无二致。中断处理程序与其它内核函数的真正区别在于，中断处理程序是被内核调用来响应中断的，而它们运行于我们称之为中断上下文的特殊上下文中。关于中断上下文，我们将在后面讨论。

中断可能随时发生，因此中断处理程序也就随时可能执行。所以必须保证中断处理程序能够快速执行，这样才能保证尽可能快地恢复被中断代码的执行。因此，尽管对硬件而言，迅速对其中断进行服务非常重要。但对系统的其它部分而言，让中断处理程序在尽可能短的时间内完成执行也同样重要。

即使最精简版的中断服务程序，它也要与硬件进行交互，告诉该设备中断已被接收。但通常我们不能像这样给中断服务程序随意减负，相反，我们要靠它完成大量的其它工作。作为一个例子，我们可以考虑一下网络设备的中断处理程序面临的挑战。该处理程序除了要对硬件应答，还要把来自硬件的网络数据包拷贝到内存，对其进行处理后再交给合适的协议栈或应用程序。显而易见，这种运动量不会太小。

 

现在我们来分析一下Linux操作系统为了支持中断机制，具体都需要做些什么工作。
       首先，操作系统必须保证新的中断能够被支持。计算机系统硬件留给外设的是一个统一的中断信号接口。它固化了中断信号的接入和传递方法，拿PC机来说，中断机制是靠两块8259和CPU协作实现的。外设要做的只是把中断信号发送到8259的某个特定引脚上，这样8259就会为此中断分配一个标识——也就是通常所说的中断向量，通过中断向量，CPU就能够在以中断向量为索引的表——中断向量表——里找到中断服务程序，由它决定具体如何处理中断。（具体细节还请查阅参考资料1，对于为何采用这种机制，该资料有精彩描述）这是硬件规定的机制，软件只能无条件服从。

因此，操作系统对新中断的支持，说简单点，就是维护中断向量表。新的外围设备加入系统，首先得明确自己的中断向量号是多少，还得提供自身中断的服务程序，然后利用Linux的内核调用界面，把〈中断向量号、中断服务程序〉这对信息填写到中断向量表中去。这样CPU在接收到中断信号时就会自动调用中断服务程序了。这种注册操作一般是由设备驱动程序完成的。

其次，操作系统必须提供给程序员简单可靠的编程界面来支持中断。中断的基本流程前面已经讲了，它会打断当前正在进行的工作去执行中断服务程序，然后再回到先前的任务继续执行。这中间有大量需要解决问题：如何保护现场、嵌套中断如何处理等等，操作系统要一一化解。程序员，即使是驱动程序的开发人员，在写中断服务程序的时候也很少需要对被打断的进程心存怜悯。（当然，出于提高系统效率的考虑，编写驱动程序要比编写用户级程序多一些条条框框，谁让我们顶着系统程序员的光环呢？）

操作系统为我们屏蔽了这些与中断相关硬件机制打交道的细节，提供了一套精简的接口，让我们用极为简单的方式实现对实际中断的支持，Linux是怎么完美的做到这一点的呢？

 

CPU对中断处理的流程：

我们首先必须了解CPU在接收到中断信号时会做什么。没办法，操作系统必须了解硬件的机制，不配合硬件就寸步难行。现在我们假定内核已被初始化，CPU在保护模式下运行。

 

CPU执行完一条指令后，下一条指令的逻辑地址存放在cs和eip这对寄存器中。在执行新指令前，控制单元会检查在执行前一条指令的过程中是否有中断或异常发生。如果有，控制单元就会抛下指令，进入下面的流程：

1.确定与中断或异常关联的向量i (0<= i <=255)。
2.籍由idtr寄存器从IDT表中读取第i项（这里我们假定该IDT表项中包含的是一个中断门或一个陷阱门）。
3.从gdtr寄存器获得GDT的基地址，并在GDT表中查找，以读取IDT表项中的选择符所标识的段描述符。这个描述符指定中断或异常处理程序所在段的基地址。
4.确信中断是由授权的（中断）发生源发出的。首先将当前特权级CPL（存放在cs寄存器的低两位）与段描述符（即DPL，存放在GDT中）的描述符特权级比较，如果CPL小于DPL，就产生一个“通用保护”异常，因为中断处理程序的特权不能低于引起中断的程序的特权。对于编程异常，则做进一步的安全检查：比较CPL与处于IDT中的门描述符的DPL，如果DPL小于CPL，就产生一个“通用保护”异常。这最后一个检查可以避免用户应用程序访问特殊的陷阱门或中断门。
5.检查是否发生了特权级的变化，也就是说， CPL是否不同于所选择的段描述符的DPL。如果是，控制单元必须开始使用与新的特权级相关的栈。通过执行以下步骤来做到这点：

    a.读tr寄存器，以访问运行进程的TSS段。
    b.用与新特权级相关的栈段和栈指针的正确值装载ss和esp寄存器。这些值可以在TSS中找到（参见第三章的“任务状态段”一节）。
     c.在新的栈中保存ss和esp以前的值，这些值定义了与旧特权级相关的栈的逻辑地址。

 

6.如果故障已发生，用引起异常的指令地址装载cs和eip寄存器，从而使得这条指令能再次被执行。

7.在栈中保存eflag、cs及eip的内容。

8.如果异常产生了一个硬错误码，则将它保存在栈中。

9.装载cs和eip寄存器，其值分别是IDT表中第i项门描述符的段选择符和偏移量域。这些值给出了中断或者异常处理程序的第一条指令的逻辑地址。 

 

控制单元所执行的最后一步就是跳转到中断或者异常处理程序。换句话说，处理完中断信号后，控制单元所执行的指令就是被选中的处理程序的第一条指令。

       中断或异常被处理完后，相应的处理程序必须产生一条iret指令，把控制权转交给被中断的进程，这将迫使控制单元：

1.用保存在栈中的值装载cs、eip、或eflag寄存器。如果一个硬错误码曾被压入栈中，并且在eip内容的上面，那么，执行iret指令前必须先弹出这个硬错误码。

2.检查处理程序的CPL是否等于cs中最低两位的值（这意味着被中断的进程与处理程序运行在同一特权级）。如果是，iret终止执行；否则，转入下一步。

3. 从栈中装载ss和esp寄存器，因此，返回到与旧特权级相关的栈。
4.       检查ds、es、fs及gs段寄存器的内容，如果其中一个寄存器包含的选择符是一个段描述符，并且其DPL值小于CPL，那么，清相应的段寄存器。控制单元这么做是为了禁止用户态的程序（CPL=3）利用内核以前所用的段寄存器（DPL=0）。如果不清这些寄存器，怀有恶意的用户程序就可能利用它们来访问内核地址空间。

再次，操作系统必须保证中断信息能够高效可靠的传递

Linux中断处理程序的注册和注销
这里参考Jollen的“Linux 驅動程式的中斷處理, #1: request_irq 基本觀念”
linux中名为“interrupt handler”的routine（ISR）负责处理（响应）中断，interrupt handler执行在中断上下文中，所以：
1. 由於沒有 process context 的關係，因此無法存取 user space。
2. 无法读取 current 。current 是一個指向当前进程的 kernel symbol。
3. 不能调用 scheduler 进行调度，也不能做 sleeping waiting。由於 down/up 的 semaphore API 是 sleeping waiting 的版本，因此在 interrupt mode 必須改用 spinlock，spinlock 是以 busy waiting 的方式做 wait operation。

linux中通过request_irq() 函数注册中断服务程序：
request_irq() 在<linux/sched.h>中声明：
int request_irq( unsigned int        irq,
                         irqreturn_t      (*handler)(int, void *, struct pt_regs *),
                         unsigned long  flags,
                         const char      *dev_name,
                          void             *dev_id);
通过free_irq()函数注销中断服务程序：
int free_irq( unsigned int irq, void *dev_id);

参数说明：
request_irq返回0 表成功，返回-EBUSY表示中断信号线已被占用
irq：要申请的中断号
handler：中断处理函数指针
dev_name：用来在/proc/interrupts中显示中断的拥有者
dev_id：用于共享的中断线中各中断源的唯一标识，一般指向驱动程序的私有数据（如device结构）。非共享时设为NULL
flags中设置的位如下：
1. SA_INTERRUPT  快速中断
2. SA_SHIRQ         共享中断
3. SA_SAMPLE_RANDOM   中断能对熵池（entropy pool）有贡献。
注意：上面的Flags设置在2.6.24之后的内核版本中不再出现
我们在2.6.24之前的版本/linux/interrupt.h中可以看到关于SA_XXX宏的描述
/*
 * Migration helpers. Scheduled for removal in 9/2007
 * Do not use for new code !
 */
在linux/kernel/irq/manage.c的request_irq的函数定义前的注释中：
Flags:
 IRQF_SHARED        Interrupt is shared
 IRQF_DISABLED    Disable local interrupts while processing
 IRQF_SAMPLE_RANDOM    The interrupt can be used for entropy
所以在新的内核代码中使用上面的宏！

中断处理函数可以在驱动程序初始化时（xxx_init)，或者设备第一次打开时安装。但因为中断线有限，容易造成中断资源浪费。
调用request_irq的正确位置应该是在设备第一次打开（xxx_open）、硬件被告知产生中断之前，调用free_irq的位置是最后一次关闭设备（xxx_close）、硬件被告知不再使用中断处理器之后。这种技术的缺点是必须为每个设备维护一个打开计数。

Linux如何处理共享中断
Linux可以让多个设备共享一个中断号，而且共享同一中断的中断处理程序形成一个链表，内核对每个中断处理程序都要执行，那么，没有产生中断的设备本
该靠边站的，它的中断处理程序也被执行了？到底是怎么会事？实际上： 
    共享的处理程序与非共享的处理程序在注册和运行方式上比较相似，但差异主要有以下三处：
* request_irq()的参数flags必须设置SA_SHIRQ标志。
* 对每个注册的中断处理程序来说，dev_id参数必须唯一。指向任一设备结构的指针就可以满足这一要求；通常会选择设备结构，因为它是唯一的，而且中断处理程序可能会用到它。不能给共享的处理程序传递NULL值。
* 中断处理程序必须能够区分它的设备是否真的产生了中断。这既需要硬件的支持，也需要处理程序中有相关的处理逻辑。如果硬件不支持这一功能，那中断处理程序肯定会束手无策，它根本没法知道到底是与它对应的设备发出了这个中断，还是共享这条中断线的其他设备发出了这个中断。
所有共享中断线的驱动程序都必须满足以上要求。只要有任何一个设备没有按规则进行共享，那么中断线就无法共享了。指定SA_SHIRQ标志以调用request_irq()时，只有在以下两种情况下才可能成功：中断线当前未被注册，或者在该线上的所有已注册处理程序都指定了SA_SHIRQ。注意，在这一点上2.6与以前的内核是不同的，共享的处理程序可以混用SA_ INTERRUPT。
内核接收一个中断后，它将依次调用在该中断线上注册的每一个处理程序。因此，一个处理程序必须知道它是否应该为这个中断负责。如果与它相关的设备并没有产生中断，那么处理程序应该立即退出。这需要硬件设备提供状态寄存器（或类似机制），以便中断处理程序进行检查。毫无疑问，大多数硬件都提供这种功能

中断处理的软中断（softirq）机制
软中断使用的比较少，tasklet是下半部的更常用的一种形式。
软中断是在编译期间静态分配的。不像tasklet那样能动态的注册或删除。
软中断保留给系统中对时间要求最严格以及最重要的下半部使用。目前只有两个子系统——网络和SCSI——直接使用软中断。此外，内核定时器和tasklet都是建立在软中断上的

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

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

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

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

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

小任务机制   

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

struct tasklet_struct {
        struct tasklet_struct *next;         /*指向链表中的下一个结构*/
        unsigned long state;                /* 小任务的状态*/
        atomic_t count;        /* 引用计数器*/
        void(*func) (unsigned long);                /* 要调用的函数*/
        unsigned long data;                 /* 传递给函数的参数*/
}；
结构中的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);
这行代码其实等价于
struct tasklet_struct my_tasklet = { NULL, 0, ATOMIC_INIT(0),
                                    tasklet_handler,dev};
这样就创建了一个名为my_tasklet的小任务，其处理程序为tasklet_handler，并且已被激活。当处理程序被调用的时候，dev就会被传递给它。
2.  编写自己的小任务处理程序小任务处理程序必须符合如下的函数类型：
void tasklet_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的一个简单应用,以模块的形成加载。
#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  tasklet_struct my_tasklet;

static void tasklet_handler (unsigned long data)
{
        printk(KERN_ALERT "tasklet_handler is running./n");
}

static int __init test_init(void)
{
        tasklet_init(&my_tasklet,tasklet_handler,0);
        tasklet_schedule(&my_tasklet);
        return0;
}

static  void __exit test_exit(void)
{
        tasklet_kill(&my_tasklet);
        printk(KERN_ALERT "test_exit is running./n");
}
MODULE_LICENSE("GPL");
module_init(test_init);
module_exit(test_exit);

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

中断处理的工作队列机制

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

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

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

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

表示工作的数据结构

工作用<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; /* 延迟的工作队列所用到的定时器 */

};
在2.6.22版本内核之后work_struct改成：
struct work_struct {
    atomic_long_t data;
#define WORK_STRUCT_PENDING 0        /* T if work item pending execution */
#define WORK_STRUCT_FLAG_MASK (3UL)
#define WORK_STRUCT_WQ_DATA_MASK (~WORK_STRUCT_FLAG_MASK)
    struct list_head entry;
    work_func_t func;
};
typedef void (*work_func_t)(struct work_struct *work);

这些结构被连接成链表。当一个工作者线程被唤醒时，它会执行它的链表上的所有工作。工作被执行完毕，它就将相应的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);
在2.6.22版本内核之后上面两个宏去掉了data参数：
       DECLARE_WORK(name, work_func_t func);
     INIT_WORK(struct work_struct *work, work_func_t func);

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

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

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

void work_handler(void *data)
在2.6.22版本内核之后改成：
typedef void (*work_func_t)(struct work_struct *work);

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

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>

static struct workqueue_struct *queue = NULL;
static struct work_struct work;

static void work_handler(struct work_struct *data)
{
        printk(KERN_ALERT "work handler function./n");
}

static int __init test_init(void)
{
        queue = create_singlethread_workqueue("helloworld"); /*创建一个单线程的工作队列*/
        if (!queue)
                goto err;

        INIT_WORK(&work, work_handler);
        schedule_work(&work);

        return 0;
err:
        return -1;
}

static void __exit test_exit(void)
{
        destroy_workqueue(queue);
}
MODULE_LICENSE("GPL");
module_init(test_init);
module_exit(test_exit);