- 论坛徽章:
- 0
|
回复 #45 sudy 的帖子
关于中断优先级(IRQL),我觉得应该从两个方面来看:OS和硬件。两者相互联系,又相互区别:)
先从OS来看吧,为什么要IRQL呢,直接的好处就是抽象啰,不管你硬件是什么样子,我都可以抽象出一个中断优先级来。经典的例子就是Windows了,从NT4.0起就有这个东东了吧?优先级一共有32个,从0~31,数字越大优先级越高,依次是Passive,APC,DPC,Device n, clock, ipi,high。有了这个抽象之后呢,kernel开发者就幸福啦,到某个优先级,我直接raise/low就可以了。
在从硬件的角度来看,外部设备产生的中断是否有优先级,或者优先级是否可以编程,这些都是在中断控制器上实现的吧,比如PIC,设备的终端优先级就是固定了的吧,timer的中断就是最高的。
那剩下的就是怎样将OS抽象出来的IRQL map到硬件上去,这就是HAL要做的事情啦。举最简单的例子,怎样将windows的32个中断优先级map到PIC上:首先是device这一级的中断优先级和PIC上设备IRQ号对应,剩下的就是如何处理低于硬件中断的irql和高于硬件中断的irql了。对低于硬件中断的irql(passive,apc,dpc),能想到的方法就是中断优先级队列了(hmm,这个跟linux的 softirq/tasklet比较像了哇),对高于硬件中断的irql呢,那就mask掉所有的硬件中断,然后在排队就实现了吧。这也说明IRQL不一定就是在APIC下才能实现了。BTW:在nt4.0的年代已经有apic了吗(不清楚。。。)?还有一个问题就是,APIC里面一定要添加TPR吗?按照前面的推理,不用TPR,直接mask中断呢?有了TPR之后呢,或许只是方便了使用(不知道对不对,大胆假设。。)
从上面的分析,可以得出Linux里面并没有像windows那样完整的关于IRQL的东东。
个人愚见,欢迎板砖。。。 |
|