中断嵌套

linux2.4.0内核中断嵌套处理，可能性分析如下：

1，同一中断线：是否可嵌套，取决于ack是否发屏蔽中断线信号给硬件？
可嵌套中断：
场景：[cpu0 A进程 i ii] [cpu1 B进程] ，先i中断执行后执行ii。若有iii，同理。
两中断（i及ii）被中断控制器分配到同一核cpu0处理，此时使用的堆栈空间均为A的
i ii中断嵌套处理使用边缘触发方式，即i在可中断环境 handle_IRQ_event中处理未返回，ii中断进入do_IRQ流程，发现此时i未完成(简单这样理解)，不做handle_IRQ_event处理即刻返回，多嵌套同理。返回i中断处理时，判断当前中断线是否有pending，因该场景pending者ii，为保证所有中断都得到处理机会，会触发再遍历处理一次，ii得以处理。

场景：[cpu0 A进程 i] [cpu1 B进程 ii]
两中断（i及ii）分别被中断控制器分配到cpu0 cpu1中处理 此时各自使用命中进程的堆栈空间，此时无中断嵌套。

不可嵌套中断：
在进入do_IRQ时便ack屏蔽了该中断线，使得同一中断线上中断无法嵌套。
场景：[cpu0 A进程 i ii] [cpu1 B进程]
严格串行化处理
场景：[cpu0 A进程 i] [cpu1 B进程 ii]
处理等同于可嵌套中断的场景：[cpu0 A进程 i] [cpu1 B进程 ii]

2，混合中断线：不同中断线定是可以中断嵌套的
若同线可嵌套：
场景：[cpu0 A进程 i ii iii] [cpu1 B进程]，其中：i ii iii同线。
i 先中断 后ii中断嵌套 又i与iii中断嵌套
iii可边缘触发对本端cpu0 ii（未处理直接返回了）的处理。
场景：[cpu0 A进程 i ii iii] [cpu1 B进程 iiii]，其中：i ii iiii同线。
i 先中断 后ii中断嵌套 又i与iii中断嵌套
iiii可边缘触发对对端cpu0 ii（未处理直接返回了）的处理。

若同线不可嵌套：
场景：[cpu0 A进程 i ii iii] [cpu1 B进程 iiii]，其中：i iii iiii同线
i 先中断 后ii中断嵌套 又ii与iii中断嵌套 iiii最后中断。
iiii可边缘触发对iii（未处理直接返回了）的处理。
无所谓对本端cpu中断的边缘触发

linux2.4.0 vs linux2.6.37（其实2.6以上基本相同了）
1>、后者只允许不同线的嵌套中断，在检测到来自同一中断线的中断时会发送ack屏蔽该中断线，前者若不管是相同中断线还是不同中断线都允许中断嵌套。引出问题：若存在256中断号，则对于后者来说，极端情况也就被中断嵌套255次，而前者会是无限次。
2>、前者中断处理占用命中进程的堆栈空间，后者在中断处理时有堆栈环境的切换动作，有独立的中断栈。问题：中断多时前者会出现堆栈溢出。