Linux编程细节5-内核-中断异常

http://www.uml.org.cn/embeded/201304021.asp

1 中断和异常

 产生的位置发生的时刻时序中断CPU外部随机异步异常CPU内部一条指令终止执行后同步

中断（异常）一般分为异步中断(一般由硬件引起)和同步中断(一般由处理器本身引起)。

异步中断（中断）：CPU处理中断的时间过长，所以先将硬件复位，使硬件可以继续自己的工作，然后在适当时候处理中断请求中耗时的部分。
举个例子：网卡的工作原理
    网卡收到数据包后，向CPU发出中断信号，请求处理接收到的数据包
    CPU将收到的数据包拷贝到内存后，即通知网卡继续工作
    至于数据包拷贝至内存后的处理会在适当的时候进行
 
这样做避免了处理数据包时间过长导致网卡接收数据包速度变慢。

同步中断（异常）：CPU处理完中断请求的所有工作后才反馈硬件
举个例子：系统异常处理(比如运算中的除0操作)
    应用程序出现异常后，需要内核来处理
    内核调用相应的异常处理函数来处理异常
    处理完后终了应用程序或者给出message
 
同步中断应该处理能很快完成的一种中断。

2 中断

2.1 中断定义

为了提高CPU和外围硬件(硬盘，键盘，鼠标等等)之间协同工作的性能，引入了中断的机制。没有中断的话，CPU和外围设备之间协同工作可能只有轮询这个方法：CPU定期检查硬件状态，需要处理时就处理，否则就跳过。当硬件忙碌的时候，CPU很可能会做许多无用功（每次轮询都是跳过不处理）。
中断机制是硬件在需要的时候向CPU发出信号，CPU暂时停止正在进行的工作，来处理硬件请求的一种机制。

2.2 中断相关函数

1 注册中断的函数
2 释放中断的函数

3 中断处理程序的声明

4 执行流程函数

2.2.1 中断注册函数

request_irq用于实现中断的注册功能:

/* * irg     - 表示要分配的中断号 * handler - 实际的中断处理程序 * flags   - 标志位，表示此中断的具有特性 * name    - 中断设备名称的ASCII 表示，这些会被/proc/irq和/proc/interrupts文件使用 * dev     - 用于共享中断线，多个中断程序共享一个中断线时(共用一个中断号)，依靠dev来区别各个中断程序 * 返回值： * 执行成功：0 * 执行失败：非0 */int request_irq(unsigned int irq,                irq_handler_t handler,                unsigned long flags,                const char* name,                void *dev)

a）中断注册(中断标志)

在flags参数中,可以选择一些与中断管理有关的选项,如:
1）IRQF_DISABLED(SA_INTERRUPT)
如果设置该位,表示是一个“快速”中断处理程序;如果没有设置这位,那么是一个“慢速”中断处理程序。
2）IRQF_SHARED(SA_SHIRQ)
该位表明中断可以在设备间共享。

b）快速/慢速中断
这两种类型的中断处理程序的主要区别在于:快速中断保证中断处理的原子性(不被打断),而慢速中断则不保证。换句话说,也就是“开启中断”标志位(处理器IF)在运行快速中断处理程序时是关闭的,因此在服务该中断时,不会被其他类型的中断打断;而调用慢速中断处理时,其它类型的中断仍可以得到服务。

c） 共享中断
共享中断就是将不同的设备挂到同一个中断信号线上。Linux对共享的支持主要是为PCI设备服务。共享中断也是通过request_irq函数来注册的,但有三个特别之处:
1）申请共享中断时,必须在flags参数中指定 IRQF_SHARED位
2）dev_id参数必须是唯一的。
3）共享中断的处理程序中,不能使用disable_irq(unsigned int irq) 为什么? 如果使用了这个函数,共享中断信号线的其它设备将同样无法使用中断,也就无法正常工作了。

2.2.2 释放中断函数

void free_irq(unsigned int irq, void *dev)

如果不是共享中断线，则直接删除irq对应的中断线。
如果是共享中断线，则判断此中断处理程序是否中断线上的最后一个中断处理程序，
    是最后一个中断处理程序 -> 删除中断线和中断处理程序
    不是最后一个中断处理程序 -> 删除中断处理程序

2.2.3 中断处理程序的声明

什么是中断处理程序,有何特别之处?中断处理程序就是普通的C代码。特别之处在于中断处理程序是在中断上下文中运行的,它的行为受到某些限制:
1） 不能向用户空间发送或接受数据
2） 不能使用可能引起阻塞的函数
3） 不能使用可能引起调度的函数

/*  * 中断处理程序的声明 * @irp  - 中断处理程序(即request_irq()中handler)关联的中断号 * @dev  - 与 request_irq()中的dev一样，表示一个设备的结构体 * 返回值： * irqreturn_t -  执行成功：IRQ_HANDLED  执行失败：IRQ_NONE */static irqreturn_t intr_handler(int, irq, void *dev)

2.2.4 执行流程函数

中断处理的过程主要涉及3函数：
do_IRQ 与体系结构有关，对所接收的中断进行应答
handle_IRQ_event 调用中断线上所有中断处理
ret_from_intr 恢复寄存器，将内核恢复到中断前的状态

2.3 最简单的中断机制

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

这种方式在原来的单片机课程中常常用到，一些简单的单片机系统也是这样用。
它的好处很明显，简单，直接。

2.4 下半部

中断处理（下半部）--推后处理的部分
Linux中断下半部处理有三种方式：软中断、tasklet、工作队列。

中断处理函数所作的第一件事情是什么？答案是屏蔽中断（或者是什么都不做，因为常常是如果不清除IF位，就等于屏蔽中断了），当然只屏蔽同一种中断。之所以要屏蔽中断，是因为新的中断会再次调用中断处理函数，导致原来中断处理现场的破坏。即，破坏了 interrupt context。
随着系统的不断复杂，中断处理函数要做的事情也越来越多，多到都来不及接收新的中断了。于是发生了中断丢失，这显然不行，于是产生了新的机制：分离中断接收与中断处理过程。中断接收在屏蔽中断的情况下完成；中断处理在时能中断的情况下完成，这部分被称为中断下半部。


从上图中看，只看int0的处理。Func0为中断接收函数。中断只能简单的触发func0，而func0则能做更多的事情，它与funcA之间可以使用队列等缓存机制。当又有中断发生时，func0被触发，然后发送一个中断请求到缓存队列，然后让funcA去处理。
由于func0做的事情是很简单的，所以不会影响int0的再次接收。而且在func0返回时就会使能int0，因此funcA执行时间再长也不会影响int0的接收。

2.4.1 软中断

下面看看linux中断处理。作为一个操作系统显然不能任由每个中断都各自为政，统一管理是必须的。
我们不可中断部分的共同部分放在函数do_IRQ中，需要添加中断处理函数时，通过request_irq实现。下半部放在do_softirq中，也就是软中断，通过open_softirq添加对应的处理函数。

2.4.2 tasklet

旧事物跟不上历史的发展时，总会有新事物出现。随着中断数的不停增加，软中断不够用了，于是下半部又做了进化。软中断用轮询的方式处理。假如正好是最后一种中断，则必须循环完所有的中断类型，才能最终执行对应的处理函数。显然当年开发人员为了保证轮询的效率，于是限制中断个数为32个。
为了提高中断处理数量，顺道改进处理效率，于是产生了tasklet机制。
Tasklet采用无差别的队列机制，有中断时才执行，免去了循环查表之苦。
CDMA因为频谱重叠问题，必须降功率。而功率降低后，又发现原来功率低了有助于环保。
Tasklet作为一种新机制，显然可以承担更多的优点。正好这时候SMP越来越火了，因此又在tasklet中加入了SMP机制，保证同种中断只
在一个cpu上执行。在软中断时代，显然没有这种考虑。因此同一种中断可以在两个cpu上同时执行，很可能造成冲突。



总结下tasklet的优点：
（1）无类型数量限制；
（2）效率高，无需循环查表；
（3）支持SMP机制；

2.4.3 工作队列

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


Tasklet其实也不一定是在中断上下文中执行，它也有可能在线程中执行。
假如中断数量很多，而且这些中断都是自启动型的（中断处理函数会导致新的中断产生），则有可能cpu一直在这里执行中断处理函数，会导致用户进程永远得不到调度时间。
为了避免这种情况，linux发现中断数量过多时，会把多余的中断处理放到一个单独的线程中去做，就是ksoftirqd线程。这样又保证了中断不多时的响应速度，又保证了中断过多时不会把用户进程饿死。

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

3 异常

xxx