本文共 7910 字，大约阅读时间需要 26 分钟。
中断是Linux内核驱动程序中非常重要的地方，但实际上，中断处理程序也没有什么与众不同的地方，它们也就是普通的C程序。
唯一独特的地方就是处理程序是在中断时间内运行的，因此它的行为会受到一些限制。这些限制与我们的内核定时器中看到的一样。
a)处理例程不能想用户空间发送或接受数据，因为它不是在任何进程的上下文中执行的.
b)处理例程也不能做任何可能发生休眠的操作，例如wait_event、使用不带GFP_ATOMIC标志的内存分配操作，或者锁住一个信号量等等。
c)最后处理例程不能调用schdule函数。
无论是快速还是慢速处理例程，程序员都应该编写执行时间尽可能短的处理例程。如果需要执行一个长时间的计算任务，最好的方法就是使用tasklet或者工作队列在更安全的时间内调度计算任务。
Linux通过将中断处理例程分成两部分来解决这个问题。称为“上半部”的部分，是实际响应中断的例程，也就是用request_irq注册的中断例程；而所谓的“下半部”是一个被上半部调度，并在稍后更安全的时间内执行的例程。上半部处理例程和下半部处理例程之间最大的不同，就是当下半部处理例程执行时，所有的中断都是打开的——这就是所谓的在更安全的时间内运行。典型情况是上半部保存设备的数据到一个设备特定的缓冲区并调度它的下半部，然后退出：这个操作是非常快的。然后在下半部执行其他必要的工作，例如唤醒进程、启动另外I/O操作等等。这种方式允许在下半部工作期间，上半部还可以继续为新的中断服务。
（1）上半部和下半部的区别 上半部指的是中断处理程序，下半部则指的是一些虽然与中断有相关性但是可以延后执行的任务。举个例子：在网络传输中，网卡接收到数据包这个事件不一定需要马上被处理，适合用下半部去实现；但是用户敲击键盘这样的事件就必须马上被响应，应该用中断实现。 两者的主要区别在于：中断不能被相同类型的中断打断，而下半部依然可以被中断打断；中断对于时间非常敏感，而下半部基本上都是一些可以延迟的工作。由于二者的这种区别，所以对于一个工作是放在上半部还是放在下半部去执行，可以参考下面四条： a）如果一个任务对时间非常敏感，将其放在中断处理程序中执行。 b）如果一个任务和硬件相关，将其放在中断处理程序中执行。 c）如果一个任务要保证不被其他中断（特别是相同的中断）打断，将其放在中断处理程序中执行。 d）其他所有任务，考虑放在下半部去执行。
（2）为什么要使用软中断？ 软中断作为下半部机制的代表，是随着SMP（share memory processor）的出现应运而生的，它也是tasklet实现的基础（tasklet实际上只是在软中断的基础上添加了一定的机制）。软中断一般是“可延迟函数”的总称，有时候也包括了tasklet（请读者在遇到的时候根据上下文推断是否包含tasklet）。它的出现就是因为要满足上面所提出的上半部和下半部的区别，使得对时间不敏感的任务延后执行，而且可以在多个CPU上并行执行，使得总的系统效率可以更高。它的特性包括： a）产生后并不是马上可以执行，必须要等待内核的调度才能执行。软中断不能被自己打断，只能被硬件中断打断（上半部）。 b）可以并发运行在多个CPU上（即使同一类型的也可以）。所以软中断必须设计为可重入的函数（允许多个CPU同时操作），因此也需要使用自旋锁来保护其数据结构。
（3）为什么要使用tasklet？（tasklet和软中断的区别） 由于软中断必须使用可重入函数，这就导致设计上的复杂度变高，作为设备驱动程序的开发者来说，增加了负担。而如果某种应用并不需要在多个CPU上并行执行，那么软中断其实是没有必要的。因此诞生了弥补以上两个要求的tasklet。它具有以下特性： a）一种特定类型的tasklet只能运行在一个CPU上，不能并行，只能串行执行。 b）多个不同类型的tasklet可以并行在多个CPU上。 c）软中断是静态分配的，在内核编译好之后，就不能改变。但tasklet就灵活许多，可以在运行时改变（比如添加模块时）。 tasklet是在两种软中断类型的基础上实现的，但是由于其特殊的实现机制（将在4.3节详细介绍），所以具有了这样不同于软中断的特性。而由于这种特性，所以降低了设备驱动程序开发者的负担，因此如果不需要软中断的并行特性，tasklet就是最好的选择。
（4）可延迟函数（软中断及tasklet）的使用 一般而言，在可延迟函数上可以执行四种操作：初始化/激活/执行/屏蔽。屏蔽我们这里不再叙述，前三个则比较重要。下面将软中断和tasklet的三个步骤分别进行对比介绍。
（4.1）初始化 初始化是指在可延迟函数准备就绪之前所做的所有工作。一般包括两个大步骤：首先是向内核声明这个可延迟函数，以备内核在需要的时候调用；然后就是调用相应的初始化函数，用函数指针等初始化相应的描述符。 如果是软中断则在内核初始化时进行，其描述符定义如下：
struct softirq_action { void (*action)(struct softirq_action *); void *data; };
在\kernel\softirq.c文件中包括了32个描述符的数组static struct softirq_action softirq_vec[32]；但实际上只有前6个已经被内核注册使用（包括tasklet使用的HI_SOFTIRQ/TASKLET_SOFTIRQ和网络协议栈使用的NET_TX_SOFTIRQ/NET_RX_SOFTIRQ，还有SCSI存储和系统计时器使用的两个），剩下的可以由内核开发者使用。需要使用函数： void open_softirq(int nr, void (*action)(struct softirq_action*), void *data) 初始化数组中索引为nr的那个元素。需要的参数当然就是action函数指针以及data。例如网络子系统就通过以下两个函数初始化软中断（net_tx_action/net_rx_action是两个函数）：
open_softirq(NET_TX_SOFTIRQ,net_tx_action); open_softirq(NET_RX_SOFTIRQ,net_rx_action);
这样初始化完成后实际上就完成了一个一一对应的关系：当内核中产生到NET_TX_SOFTIRQ软中断之后，就会调用net_tx_action这个函数。 tasklet则可以在运行时定义，例如加载模块时。定义方式有两种： 静态声明
DECLARE_TASKET(name, func, data) DECLARE_TASKLET_DISABLED(name, func, data)
动态声明
void tasklet_init(struct tasklet_struct *t, void (*func)(unsigned long), unsigned long data)
其参数分别为描述符，需要调用的函数和此函数的参数—必须是unsigned long类型。也需要用户自己写一个类似net_tx_action的函数指针func。初始化最终生成的结果就是一个实际的描述符，假设为my_tasklet（将在下面用到）。
（4.2）激活 激活标记一个可延迟函数为挂起（pending）状态，表示内核可以调用这个可延迟函数（即使在中断过程中也可以激活可延迟函数，只不过函数不会被马上执行）；这种情况可以类比处于TASK_RUNNING状态的进程，处在这个状态的进程只是准备好了被CPU调度，但并不一定马上就会被调度。 软中断使用raise_softirq()函数激活，接收的参数就是上面初始化时用到的数组索引nr。 tasklet使用tasklet_schedule()激活，该函数接受tasklet的描述符作为参数，例如上面生成的my_tasklet：
tasklet_schedule(& my_tasklet)
（4.3）执行 执行就是内核运行可延迟函数的过程，但是执行只发生在某些特定的时刻（叫做检查点，具体有哪些检查点？详见《深入》p.177）。 每个CPU上都有一个32位的掩码__softirq_pending，表明此CPU上有哪些挂起（已被激活）的软中断。此掩码可以用local_softirq_pending()宏获得。所有的挂起的软中断需要用do_softirq()函数的一个循环来处理。 而对于tasklet，由于软中断初始化时，就已经通过下面的语句初始化了当遇到TASKLET_SOFTIRQ/HI_SOFTIRQ这两个软中断所需要执行的函数：
open_softirq(TASKLET_SOFTIRQ, tasklet_action, NULL); open_softirq(HI_SOFTIRQ, tasklet_hi_action, NULL);
因此，这两个软中断是要被区别对待的。tasklet_action和tasklet_hi_action内部实现就是为什么软中断和tasklet有不同的特性的原因（当然也因为二者的描述符不同，tasklet的描述符要比软中断的复杂，也就是说内核设计者自己多做了一部分限制的工作而减少了驱动程序开发者的工作）。
（5）为什么要使用工作队列work queue？（work queue和软中断的区别） 上面我们介绍的可延迟函数运行在中断上下文中（软中断的一个检查点就是do_IRQ退出的时候），于是导致了一些问题：软中断不能睡眠、不能阻塞。由于中断上下文出于内核态，没有进程切换，所以如果软中断一旦睡眠或者阻塞，将无法退出这种状态，导致内核会整个僵死。但可阻塞函数不能用在中断上下文中实现，必须要运行在进程上下文中，例如访问磁盘数据块的函数。因此，可阻塞函数不能用软中断来实现。但是它们往往又具有可延迟的特性。 因此在2.6版的内核中出现了在内核态运行的工作队列（替代了2.4内核中的任务队列）。它也具有一些可延迟函数的特点（需要被激活和延后执行），但是能够能够在不同的进程间切换，以完成不同的工作。
软中断、bh及tasklet的初始化
1． Tasklet的初始化
Tasklet的初始化是由tasklet_ init()函数完成的：
void tasklet_init(struct tasklet_struct *t,
void (*func)(unsigned long), unsigned long data)
{
t->next = NULL;
t->state = 0;
atomic_set(&t->count, 0);
t->func = func;
t->data = data;
}
其中，atomic_set()为原子操作,它把t->count置为0。
2．软中断的初始化
首先通过open_softirq()函数打开软中断：
void open_softirq(int nr, void (*action)(struct softirq_action*), void *data)
{
softirq_vec[nr].data = data;
softirq_vec[nr].action = action;
｝
然后，通过softirq_init()函数对软中断进行初始化：
void __init softirq_init()
{
int i;
for (i=0; i<32; i++)
tasklet_init(bh_task_vec+i, bh_action, i);
open_softirq(TASKLET_SOFTIRQ, tasklet_action, NULL);
open_softirq(HI_SOFTIRQ, tasklet_hi_action, NULL);
}
对于bh的32个tasklet_struct，调用tasklet_init以后，它们的函数指针func全部指向bh_action（）函数，也就是建立了bh的执行机制，但具体的bh函数还没有与之挂勾，就像具体的中断服务例程还没有挂入中断服务队列一样。同样，调用open_softirq（）以后，软中断TASKLET_SOFTIRQ的服务例程为tasklet_action（），而软中断HI_SOFTIRQ的服务例程为tasklet_hi_action（）。
3．Bh的初始化
bh的初始化是由init_bh()完成的：
void init_bh(int nr, void (*routine)(void))
{
bh_base[nr] = routine;
mb();
}
这里调用的函数mb()与CPU中执行指令的流水线有关，我们对此不进行进一步讨论。下面看一下几个具体bh的初始化（在kernel/sched.c中）：
init_bh(TIMER_BH,timer_bh);
init_bh(TUEUE_BH,tqueue_bh);
init_bh(IMMEDIATE_BH,immediate_bh);
初始化以后，bh_base[TIMER_BH]处理定时器队列timer_bh，每个时钟中断都会激活TIMER_BH，在第五章将会看到，这意味着大约每隔10ms这个队列运行一次。bh_base[TUEUE_BH]处理周期性的任务队列tqueue_bh，而bh_base[IMMEDIATE_BH]通常被驱动程序所调用，请求某个设备服务的内核函数可以链接到IMMEDIATE_BH所管理的队列immediate_bh中，在该队列中排队等待。
什么是软中断机制？
Linux中的软中断机制用于系统中对时间要求最严格以及最重要的中断下半部进行使用。在系统设计过程中，大家都清楚中断上下文不能处理太多的事情，需要快速的返回，否则很容易导致中断事件的丢失，所以这就产生了一个问题：中断发生之后的事务处理由谁来完成？在前后台程序中，由于只有中断上下文和一个任务上下文，所以中断上下文触发事件，设置标记位，任务上下文循环扫描标记位，执行相应的动作，也就是中断发生之后的事情由任务来完成了，只不过任务上下文采用扫描的方式，实时性不能得到保证。在Linux系统和Windows系统中，这个不断循环的任务就是本文所要讲述的软中断daemon。在Windows中处理耗时的中断事务称之为中断延迟处理，在Linux中称之为中断下半部，显然中断上半部处理清中断之类十分清闲的动作，然后在退出中断服务程序时触发中断下半部，完成具体的功能。
在Linux中，中断下半部的实现基于软中断机制。所以理清楚软中断机制的原理，那么中断下半部的实现也就非常简单了。通过上述的描述，大家也应该清楚为什么要定义软中断机制了，一句话就是为了要处理对时间要求苛刻的任务，恰好中断下半部就有这样的需求，所以其实现采用了软中断机制。
软中断机制实现原理
软中断机制的实现原理如下图所示：
构成软中断机制的核心元素包括：
1、 软中断状态寄存器soft interrupt state（irq_stat）
2、 软中断向量表（softirq_vec）
3、 软中断守护daemon
软中断的工作工程模拟了实际的中断处理过程，当某一软中断时间发生后，首先需要设置对应的中断标记位，触发中断事务，然后唤醒守护线程去检测中断状态寄存器，如果通过查询发现某一软中断事务发生之后，那么通过软中断向量表调用软中断服务程序action（）。这就是软中断的过程，与硬件中断唯一不同的地方是从中断标记到中断服务程序的映射过程。在CPU的硬件中断发生之后，CPU需要将硬件中断请求通过向量表映射成具体的服务程序，这个过程是硬件自动完成的，但是软中断不是，其需要守护线程去实现这一过程，这也就是软件模拟的中断，故称之为软中断。
一个软中断不会去抢占另一个软中断，只有硬件中断才可以抢占软中断，所以软中断能够保证对时间的严格要求。
Linux中软中断实现分析
在Linux中最多可以注册32个软中断，目前系统用了6个软中断，他们为：定时器处理、SCSI处理、网络收发处理以及Tasklet机制，这里的tasklet机制就是用来实现下半部的，
描述软中断的核心数据结构为中断向量表，其定义如下：
struct softirq_action
{
void (*action)(struct softirq_action *); /* 软中断服务程序 */
void *data; /* 服务程序输入参数 */
};
软中断守护daemon是软中断机制的实现核心，其实现过程也比较简单，通过查询软中断状态irq_stat来判断事件是否发生，如果发生，那么映射到软中断向量表，调用执行注册的action函数就可以了。从这一点分析可以看出，软中断的服务程序的执行上下文为软中断daemon。在Linux中软中断daemon线程函数为do_softirq（）。
触发软中断事务通过raise_softirq（）来实现，该函数就是在中断关闭的情况下设置软中断状态位，然后判断如果不在中断上下文，那么直接唤醒守护daemon。
常用的软中断函数列表如下：
1、 Open_softirq，注册一个软中断，将软中断服务程序注册到软中断向量表。
2、 Raise_softirq，设置软中断状态bitmap，触发软中断事务。
Tasklet机制实现分析
Tasklet为一个软中断，考虑到优先级问题，分别占用了向量表中的0号和5号软中断。Tasklet机制的实现原理如下图所示：
当tasklet的软中断事件发生之后，执行tasklet-action的软中断服务程序，该服务程序会扫描一个tasklet的任务列表，执行该任务中的具体服务程序。在这里举一个例子加以说明：
当用户读写USB设备之后，发生了硬件中断，硬件中断服务程序会构建一个tasklet_struct，在该结构中指明了完成该中断任务的具体方法函数（下半部执行函数），然后将tasklet_struct挂入tasklet的tasklet_struct链表中，这一步可以通过tasklet_schedule函数完成。最后硬件中断服务程序退出并且CPU开始调度软中断daemon，软中断daemon会发现tasklet发生了事件，其会执行tasklet-action，然后tasklet-action会扫描tasklet_struct链表，执行具体的USB中断服务程序下半部。这就是应用tasklet完成中断下半部实现的整个过程。
Linux中的tasklet实现比较简单，其又封装了一个重要数据结构tasklet_struct，使用tasklet主要函数列表如下：
1、 tasklet_init，初始化一个tasklet_struct，当然可以采用静态初始化的方法，宏为：DECLARE_TASKLET。
2、 tasklet_schedule，调度一个tasklet，将输入的tasklet_struct添加到tasklet的链表中。
Linux中的软中断机制就是模拟了硬件中断的过程，其设计思想完全可以在其他嵌入式OS中得以应用
转自：
转载地址：http://qvcci.baihongyu.com/