Linux如何区分注册到同一个IRQ上的不同中断处理函数

Linux 2.6内核标准教程上将中断处理函数调用过程说的很清楚，
struct irq_desc_t irq_desc[NR_IRQS]里保存了所有IRQ的信息。
具体的一个IRQ ，如18，irq_desc[18]里的action成员指向一个irqaction队列。
一般这个队列长度为1，但是如果有n个设备共享一个IRQ，队列长度就是n。

irqaction队列的每一个成员都有各自的中断处理函数handler，也有一个dev_id.
struct irqaction {
irq_handler_t handler;
unsigned long flags;
cpumask_t mask;
const char *name;
void *dev_id;
struct irqaction *next;
int irq;
struct proc_dir_entry *dir;
};

如果该IRQ上有中断请求被内核响应，内核会把irqaction队列中的所有中断处理函数handler都执行一遍的。但是里面只有一个才是真正需要响应的设备。
问题就是内核如何知道谁才是真正需要执行的handler。

Linux2.6内核标准教程 居然说内核靠dev_id来区分到底应该执行哪个handler，
我觉得这是错误的。dev_id所指向的空间不会自动跟设备的行为有联系。根本就不会因为
某个设备申请中断，而使对应的设备驱动程序指定的dev_id会有什么反应。

dev_id倒是可以在删除irqaction 队列里某个元素时起到唯一标记作用，这是没有异议的。

Linux可以让多个设备共享一个中断号，而且共享同一中断的中断处理程序形成一个链表，内核对每个中断处理程序都要执行，那么，没有产生中断的设备本
该靠边站的，它的中断处理程序也被执行了？到底是怎么会事？实际上：


共享的处理程序与非共享的处理程序在注册和运行方式上比较相似，但差异主要有以下三处：
* request_irq()的参数flags必须设置SA_SHIRQ标志。
* 对每个注册的中断处理程序来说，dev_id参数必须唯一。指向任一设备结构的指针就可以满足这一要求；通常会选择设备结构，因为它是唯一的，而且
中断处理程序可能会用到它。不能给共享的处理程序传递NULL值。
* 中断处理程序必须能够区分它的设备是否真的产生了中断。这既需要硬件的支持，也需要处理程序中有相关的处理逻辑。如果硬件不支持这一功能，那中断处
理程序肯定会束手无策，它根本没法知道到底是与它对应的设备发出了这个中断，还是共享这条中断线的其他设备发出了这个中断。
所有共享中断线的驱动程序都必须满足以上要求。只要有任何一个设备没有按规则进行共享，那么中断线就无法共享了。指定SA_SHIRQ标志以调用
request_irq()时，只有在以下两种情况下才可能成功：中断线当前未被注册，或者在该线上的所有已注册处理程序都指定了SA_SHIRQ。注
意，在这一点上2.6与以前的内核是不同的，共享的处理程序可以混用SA_ INTERRUPT。
内核接收一个中断后，它将依次调用在该中断线上注册的每一个处理程序。因此，一个处理程序必须知道它是否应该为这个中断负责。如果与它相关的设备并没有
产生中断，那么处理程序应该立即退出。这需要硬件设备提供状态寄存器（或类似机制），以便中断处理程序进行检查。毫无疑问，大多数硬件都提供这种功能。

总结：该IRQ上有中断请求被内核响应，内核会把irqaction队列中的所有中断处理函数handler都执行一遍的。所以不同的设备共享同一个IRQ时，各自的中断处理函数必须首先
自己判断是否是自己的设备发生了中断。具体还是需要硬件支持，我想到的大概就是
读一个寄存器值就可以了。不是自己的中断，那就立刻返回。