内核发展出的软中断机制的原因。

软中断是利用硬件中断外部设备中断服务程序

软中断是linux系统原“底半处理”的升级，在原有的基础上发展的新的处理方式，以适应多cpu 、多线程的软中断处理。

软中断是实现系统API函数调用的手段

函数调用时将返回地址和CPU状态寄存器内容压栈，函数执行完毕后出栈返回断点继续执行。

软中断调用时将返回地址和CPU状态寄存器内容压栈，修改特权级，根据中断号查找中断向量表，找到ISR中断服务例程地址，跳转执行。

综上，函数调用和软中断调用的区别是，软中断多了修改特权级和查找中断向量表的功能，其他部分完全一样。

一般，系统程序由软件公司实现且不开源，你无法知道系统API函数的偏移地址，而且你写的应用程序和软件公司提供的系统程序是完全分开的，编译器无法将二者链接在一起，同时，系统程序需要核心态特权才能运行，此时用函数调用的办法是无法调用系统API函数的。解决这个问题的方法是使用软中断，当应用程序需要调用API时，就先设置功能号(如AX=0H)，然后触发软中断(如INT 80H)。系统程序设置好中断向量表。这样，应用程序就可以间接找到系统API了。

有了软中断，就可以实现应用程序的动态加载。就像WINDOWS/Linux那样，应用程序和系统程序分别开发，不在一起编译连接，应用程序通过软中断调用系统提供的功能。

一般来说，软中断是由内核机制的触发事件引起的（例如进程运行超时），但是不可忽视有大量的软中断也是由于和硬件有关的中断引起的，例如当打印机端口产生一个硬件中断时，会通知和硬件相关的硬中断，硬中断就会产生一个软中断并送到操作系统内核里，这样内核就会根据这个软中断唤醒睡眠在打印机任务队列中的处理进程。

Linux中的软中断机制用于系统中对时间要求最严格以及最重要的中断下半部进行使用。在系统设计过程中，大家都清楚中断上下文不能处理太多的事情，需要快速的返回，否则很容易导致中断事件的丢失，所以这就产生了一个问题：中断发生之后的事务处理由谁来完成？在前后台程序中，由于只有中断上下文和一个任务上下文，所以中断上下文触发事件，设置标记位，任务上下文循环扫描标记位，执行相应的动作，也就是中断发生之后的事情由任务来完成了，只不过任务上下文采用扫描的方式，实时性不能得到保证。在Linux系统和Windows系统中，这个不断循环的任务就是本文所要讲述的软中断daemon。在Windows中处理耗时的中断事务称之为中断延迟处理，在Linux中称之为中断下半部，显然中断上半部处理清中断之类十分清闲的动作，然后在退出中断服务程序时触发中断下半部，完成具体的功能。

在Linux中，中断下半部的实现基于软中断机制。所以理清楚软中断机制的原理，那么中断下半部的实现也就非常简单了。通过上述的描述，大家也应该清楚为什么要定义软中断机制了，一句话就是为了要处理对时间要求不那么苛刻的任务，恰好中断下半部就有这样的需求，所以其实现采用了软中断机制。

软中断机制的实现原理如图1所示：

构成软中断机制的核心元素包括：

1、 软中断状态寄存器soft interrupt state（irq_stat）

2、 软中断向量表（softirq_vec）

3、 软中断守护daemon

软中断的工作工程模拟了实际的中断处理过程，当某一软中断事件发生后，首先需要设置对应的中断标记位，触发中断事务，然后唤醒守护线程去检测中断状态寄存器，如果通过查询发现有软中断事务发生，那么通过查询软中断向量表调用相应的软中断服务程序action（）。这就是软中断的过程，与硬件中断唯一不同的地方是从中断标记到中断服务程序的映射过程。在CPU的硬件中断发生之后，CPU需要将硬件中断请求通过向量表映射成具体的服务程序，这个过程是硬件自动完成的，但是软中断不是，其需要守护线程去实现这一过程，这也就是软件模拟的中断，故称之为软中断。

一个软中断不会去抢占另一个软中断，只有硬件中断才可以抢占软中断，所以硬中断能够保证对时间的严格要求。

DOS调用和BIOS调用，是用户使用系统资源的重要方法和基本途径，也是用户编写MS—DOS应用程序使用很频繁的重要内容，应学会使用。

除了上述硬中断和软中断两类中断外，微型计算机的中断系统还包括一些特殊中断。这些中断既不是由外围设备提出申请而产生的，也不是由用户在程序中发中断指令INT nH而发生的，而是由内部的突发事件所引起的中断，即在执行指令的过程中，CPU发现某种突发事件时启动内部逻辑转去执行预先规定的中断号所对应的中断服务程序。这类中断也是不可屏蔽中断，其中断处理过程具有与软中断相同的特点，因此，有的教材把它们归入软中断这一类。这类中断有：

0号中断——除数为零中断；

1号中断——单步中断；

3号中断——断点中断；

4号中断——溢出中断。