linux内核分析笔记----上半部与下半部(上)

       嗨，嗨，如果您记性好的话，我在上一篇博客中提到过这样一件事：中断处理是分为两个部分：中断处理程序是上半部，它接收到一个中断，就立即执行，但只做有严格时限的工作；而另外被叫做下半部的另外一个部分主要做被允许能稍后完成的工作。这个下半部正是今天的重点。

       下半部的任务就是执行与中断处理密切相关但中断处理程序本生身不执行的任务。最好情况当然是中断处理程序把所有的工作都交給下半部执行，而自己啥都不做。因为我们总是希望中断处理程序尽可能快的返回。但是，中断处理程序注定要完成一部分工作。遗憾的是，并没有谁严格规定说什么任务应该在哪个部分中完成，换句话说，这个决定完全由想我们这样的驱动工程师来做。记住，中断处理程序会异步执行，并且在最好的情况下它也会锁定当前的中断线，因此将中断处理程序缩短的越小就越好。当然啦，没有规则并不是没有经验和教训：

1.如果一个任务对时间非常敏感，感觉告诉我还是将其放在中断处理程序中执行是个好的选择。 2.如果一个任务和硬件相关，还是将其放在中断处理程序中执行吧。 3.如果一个任务要保证不被其他中断(特别是相同的中断)打断，那就将其放在中断处理程序中吧。 4.其他所有任务，除非你有更好的理由，否则全部丢到下半部执行。

       总之，一句话：中断处理程序要执行的越快越好。

       我们前边老是说下半部会在以后执行，那么这个以后是个什么概念呢？遗憾的说，这个只是相对于马上而言的。下半部并需要指定一个明确的时间，只要把这个任务推迟一点，让他们在系统不太繁忙并且中断恢复后执行就可以了。通常下半部在中断处理程序已返回就会马上执行，关键在于当它们运行时，允许相应所有的中断。

       上半部只能通过中断处理程序来完成，下半部的实现却是有很多种方式。这些用来实现下半部的机制分别由不同的接口和子系统组成。最早的是“bottom half”，这种机制也被称为“BH”,它提供的接口很简单，提供了一个静态创建，由32个bottom half组成的链表，上半部通过一个32位整数中的一位来标识出哪个bottom half可执行。每个BH都在全局范围内进行同步，即使分属于不同的处理器，也不允许任何两个bottom half同时执行。这种方式使用方便但不够灵活，简单却有性能瓶颈。以需要更好的方法了。第二种方法，任务队列(task queues).内核定义了一组队列。其中每个队列都包含一个由等待调用的函数组成链表。根据其所处队列的位置，这些函数会在某个时刻被执行，驱动程序可根据需要把它们自己的下半部注册到合适的队列上去。这种方法已经不错，但仍然不够灵活，它没办法代替整个BH接口。对于一些性能要求较高的子系统，像网络部分，它也不能胜任。在2.3开发版中，又引入了软中断(softirqs)和tasklet，这里的软中断和实现系统调用所提到的软中断(软件中断)不是同一个概念。如果无须考虑和过去开发的驱动程序相兼容的话， 软中断和tasklet可以完全代替BH接口。软中断是一组静态定义的下半部接口，有32个，可以在所有的处理器上同时执行----即使两个类型完全相同。task是一种基于软中断实现的灵活性强，动态创建的下半部实现机制。两个不同类型的tasklet可以在不同的处理器上同时执行，但类型相同的tasklet不能同时执行。tasklet其实是一种在性能和易用性之间寻求平衡的产物。软中断必须在编译期间就进行静态注册，而tasklet可以通过代码进行动态注册。现在都是2.6内核了，我们说点新鲜的吧，linux2.6内核提供了三种不同形式的下半部实现机制：软中断，tasklets和工作