Linux中断完全分析

 

学习本文可以对linux中断有全面而深刻的认识。本文对Linux中断所涉及的需求、管理机制、中断实现、中断接口（上半部和下半部）、驱动使用进行完全分析。

一、中断需求

软件是需求驱动的，软件的出现是为了解决需求和问题的。先知道需求，那理解代码就是为了验证已知的问题；不知道需求，那理解代码就是揣摩设计者的目的。两者相比，前者自然效率跟高。

中断是为了解决异步的需求。紧急的事情或者更高优先级的事情需要先做，就代表异步。例如，手机需要时刻优先响应用户按键或者触摸这个事件，否则用户体验就变差。信号是软件上的异步机制，而中断则是硬件上的异步机制。对于中断控制器（SOC）的设计原理请参考《软件和硬件都是对生活的高度抽象---论中断控制（ARM体系编程）》一文。

二、Linux中断需求

      上述中断需求对所有实时设备均适用，不管是高级处理器（如ARM体系手机）还是低端控制器（如51体系）。但是对于不同的体系和不同的多任务环境上，中断的需求也要进一步细分。如不同的CPU体系在内存上的表现也会不同的，高级处理器所配置的内存比较大，M级以上，而低端处理器配置的内存比较小，都是K级别。内存的大小也决定了软件代码量和复杂度。Linux操作系统适用于高级处理器和大内存，能够处理大量多任务并发执行。在多进程多线程环境下，中断的需求也变得复杂，因此Linux的中断处理也相对复杂。我们一一来分析Linux中断的需求来自哪里，以及Linux是如何应对的。

      我们设想有以下场景：假设是90年代初有某个公司就只有一台电话机（这个场景过时了，一时没想到更好的J），公司只有总经理A和主管B和员工C三个人。我们很容易想到，三者做的事情的重要性是总经理到主管再到员工。在使用电话机对外交流的时候，应该优先总经理，再到主管，最后才是员工。好，三个人常态时是在埋头工作，需求电话沟通代表了异步紧急的事情。我们逐一分析遇到的问题，并考虑怎么应对解决：

      1.先是主管B遇到紧急事情需要打断手头的工作去电话，而总经理A在B打电话期间遇到紧急的事情也要打电话。如果主管B一直拿着电话煲粥，那总经理肯定很不爽，因为总经理的事情紧急又更重要。所以合理的处理方式是，总经理有权利抢占电话来先处理紧急的事情。这就是在软件上要允许中断嵌套，让更高优先级的中断能够得到的及时的响应。

      2.主管B在打电话的时候，如果员工C遇到紧急的事情也要打电话，他自然是不能抢来打的。这样就引发一个这样的问题，如果B一直占着电话不放，这样合理吗？主管B跟客户肯定是先把紧急的事情（设为B1）说完了，然后为了维护客户关系，就跟客户吹吹水什么的（设为B2）。员工C要打电话处理紧急的事情应该要比B2更加重要吧。假设C和对方沟通完紧急的事情（设为C1）后，也跟客户吹水（设为C2）。那从公平的角度来讲，C1要比B2重要。怎么处理这种情况呢？Linux中断使用上半部和下半部机制。即将每个中断服务分成两个阶段，上半部处理硬件相关和非常紧急的操作（如读硬件数据），而下半部处理没有那么紧急的操作（将硬件数据放到队列等）；而且规定，低优先级中断的上半部可以抢占高优先级中断的下半部。即主管B的紧急处理分为B1和B2两个部分，员工C的紧急处理分为C1和C2两个部分。C1可以抢占B2进行。中断上半部和下半部机制是为了让低优先级中断也得到执行的机会。