关于windows wdm设备驱动程序开发指南――wdmio的问题

在这例子中，IRP_MJ_WRIET/IRP_MJ_READ 一部分在iostartio中用
可kesynchronizeExecution(),完成，到了中断ISR里，又有一部分
TxComplete-RunWriteCmdsSynch(dx),对未传输完毕的数据 继续进行传输。

实在不明白，书上的例子为什么这么干？

如此这般，用ISR，再用dpc ,岂不是没事找事吗 ？

那是你对系统如何响应中断机理没有完全吃透，对于共享中断的处理，I/O管理器将轮询所有共享此硬件中断的ISRs，不是该中断的设备driver的ISR返回false，并查询下一个设备的ISR，直到某个设备返回TRUE，如此这般，无论是别的设备响应该中断有可能调用本设备的ISR考虑，还是本设备再次响应该中断要避免中断嵌套考虑，显然ISR例程越短越好。

那是你对系统如何响应中断机理没有完全吃透，对于共享中断的处理，I/O管理器将轮询所有共享此硬件中断的ISRs，不是该中断的设备driver的ISR返回false，并查询下一个设备的ISR，直到某个设备返回TRUE，如此这般，无论是别的设备响应该中断有可能调用本设备的ISR考虑，还是本设备再次响应该中断要避免中断嵌套考虑，显然ISR例程越短越好。

老兄：
你没有理解我问的问题阿。
我问的是，为什么数据传输在wdmiostartio里面处理了一次，在中断里又处理了一次，中断驱动的I/O传输难道就是这样驱动的？

这位兄台：
    你好，小弟平时干些（COMPACT）PCI的设备的设计工作，兼做点不同OS的驱动程序，心得略有一二，偶尔上网逛逛，查找器件和不知道有用没用的工具，不晓得咋就看到了你提的这个问题，我只是看到了最后一句，回复得有些断章取义，请原谅，是我没有吃透你的意思。
    就事论事，一个IRP只是一个命令或操作，iostartio例程分派该任务，KesynchronizeExecution例程将当前的IRQL升到与设备的ISR相同的IRQL，获得ISR的自旋锁，并且直接调用例程****** ，该例程在运行时进行端口读写或映射内存读写，操作完成后将使设备发出中断信号，自然接下来由ISR响应中断（在DIRQL级)，然后是DPC例程（在APC_LEVEL级）。不知然否

这位兄台：
    你好，小弟平时干些（COMPACT）PCI的设备的设计工作，兼做点不同OS的驱动程序，心得略有一二，偶尔上网逛逛，查找器件和不知道有用没用的工具，不晓得咋就看到了你提的这个问题，我只是看到了最后一句，回复得有些断章取义，请原谅，是我没有吃透你的意思。
    就事论事，一个IRP只是一个命令或操作，iostartio例程分派该任务，KesynchronizeExecution例程将当前的IRQL升到与设备的ISR相同的IRQL，获得ISR的自旋锁，并且直接调用例程****** ，该例程在运行时进行端口读写或映射内存读写，操作完成后将使设备发出中断信号，自然接下来由ISR响应中断（在DIRQL级)，然后是DPC例程（在APC_LEVEL级）。不知然否

 

我也是这么认为的，只是从例子的原代码，看不出是这种处理方式。
或许这个例子有些问题！

补充一句：这种驱程模型是对临界资源的同步保护机制的一种实现，把上述3个回复倒叙合在一起，可能就是你想要的结果。