问一个中断细节方面的问题

smalloc

看来“有人”就是我了，
对于3。我只是说。因为LEVEL中断的不可丢失性可以比较直接的MASK。不会产生影响。没其他意思。

lymickey

回复 2# smalloc


   
    如果是edge方式，为何就不能mask？不是说PIC可以latch吗？

smalloc

回复 3# lymickey


    没说不能MASK，你这个估计是在新版本中才开始允许EDGE嵌套的

smalloc

回复 1# lymickey


    问题一，LEVEL必须MASK，如果不MASK，将持续发送中断。通过软件阻止嵌套是低效行为。
实际情况是处理器不停的处理中断，不停的检测没有任何实际任务执行。
问题2，不是很清楚。这个如果是个通用构架，可能MASK对有些中断无效，或者不能完全关闭。可能是个保守设计。
另外即使MASK，也有可能其他处理器已经在处理这个类型中断。ULK在讲IRQ_INPROGRESS时说这时本次中断不执行，而是留个前面那个处理去执行。

lymickey

回复 5# smalloc


   我看的 2.6.30版本，对__do_IRQ()与handle_edge_irq看起来差不多，代码中有这样一段说明：
503         /*
504          * Edge triggered interrupts need to remember
505          * pending events.
506          * This applies to any hw interrupts that allow a second
507          * instance of the same irq to arrive while we are in do_IRQ
508          * or in the handler. But the code here only handles the _second_
509          * instance of the irq, not the third or fourth. So it is mostly
510          * useful for irq hardware that does not mask cleanly in an
511          * SMP environment.
512          */

看来这就是答案了~level的mask是你说的防止不断中断，而edge这里设计的是用在允许两次中断嵌套的环境下，当然也可以加一个mask也没啥影响。

但还有一个问题没想明白，在mask的情况下，为何还要有对IRQ_INPROGRESS的判断？在mask的情况下PIC根本发不出同一种类型的irq

吾爱夏日长

在mask的情况下PIC根本发不出同一种类型的irq
、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、
不是不发生，而是暂时忽略它，不让新来的同种类型的中断处理，等待旧的中断处理完，再处理刚才pending的中断