一系列问题。。。

fdo — Thu, 02 Apr 2009 02:46:00 GMT

0.这是我在论坛问的问题
DispacherSend(....)
{
.....

WRITE_PORT_UCHAR(TRANSMIT,0x1);//这里就启动发送，在dispacher没返回pending时，isr就以及发生，dpc已经完成irp,怎么办？？？同步isr?

return STATUS_PENDING;
}
BOOLEAN OnInterrupt(..)
{
   if(TRANSMITINT)
  {
   IoRequestDpc(...)
  }

}

DpcForIsr()
{
   IoCompleteRequeset(..)
}

////////////////////////////////////////////////////////////////////////////
1.关于dispacher的irql
wdm书上irql说是dispach_level，但其他章节的叙述看来是passive_level...

2.关于dispacher的返回
返回值到底给了谁？
a)iomgr创建irp
b)iocalldriver本身是同步调用
c)如果iomgr直接iocalldriver,那么返回值给了iomgr,iomgr将做后期处理
d)DPC里iocompleterequest ，将排队dpc obj,最终可能是在apc_level做真正的返回处理

分析：假设dispacher在dispach_level调用
a)在dispacher里return pending前，可能被isr打断,
b)isr里iorequestdpc时，一个dpc入队
c)irql回到dispach_level,假设dpc rountie先于dispacher调用
d)dpc rountie 里面complete irp但所谓完成也是iocomplete obj入队。之后，dispacher应该被resume,即return pending
e)irql到apc_level,排在队列里的iocomplete被完成
f)irql回到passive_level,线程调度恢复，此时win32里的同步deviceiocontrol操作才会真正resume,而得到的值应该是iocomplete obj完成时的，具体应该在一个XXXblock的数据结构里。

这样的分析有两个条件，1）dispacher在dispach_level调用，2)从isr到dispach_level，dpcer可能先于dispacher调用。

如果条件2改为dispacher先调用，也一样，iomgr知道如何处理，我想dispacher里iomarkpending就是起这个作用的，isr来临前dispacher 其实已经放弃了irp，返回值pending到底有什么用不知。或许最终apc complete iocomplete obj时，做判断？

如果条件1改为dispacher在passive_level调用，那么win32 resume和dispacher resume应该也有抢占问题，但这个不重要，只要iomgr把markpending的irp的dispacher的返回值忽略就行。。。。。

没有符号——大陆行货（阉割版）
////////--------------------------------------------------------------------------2009.4.11
翻了翻wrk代码。实际上dispacher是回调函数，对readfile,writefile等win32 api ioctl，其真正调用者应该是iomgr-iocalldriver. 在iomgr的某段代码里面调用了iocalldriver,dispacher的返回值只关系iomgr如何处理。简单的说，iocalldriver返回pending可能会导致iomgr 阻塞。进而阻塞win32线程，实际上中间有一个细节，我想应该说是阻塞一个文件对象（驱动？）所在的上下文，最终才阻塞win32. 当然iomarkirppending可能会让iomgr选择不阻塞。

这样的话，事情就清楚了，对于一个设备——文件句柄。只能有一个IRP pending.，即使在不同的线程中，IRP的一个中间受体是文件，一旦pending就必须完成。即使是non-block IRP，我想也不行！这样的话，必须有一个完成机制，打开另个文件句柄，发个IRP停止是一种做法，walter 的例子也是这么做的，我不知道是不是标准做法，我想应该不是！

我翻阅了src/kernel/serial。它的做法是分时。我想双工driver可以仿照文件行为
1.read行为应该类似普通文件
   a) 如果下面有数据，立即返回，如果没有，启动一个timer,以便read返回，这和non-block block IOCTL关系不大。
   b) 下面是否有数据，完全决定于驱动设计。对于一个中断设备，可以选择在pending期间才处理接收中断。也可以选择缓冲数据。
c) serial也是用的这种分时方式。
2.write
a)普通文件write也是会超时的。所以write也要提供一个timer
3.显然一个文件不应该同时写和读，即使技术上能实现。

至于排队IRP，书上说，排队是提高吞吐量。我认为排队揭示了一个重要原则，必须提供取消例程。应该说实际上对于一个设备驱动，只能串行处理irp,所谓排队应该有一个隐含条件，另一个设备句柄被打开了，有一个新的irp要处理，但当前的还没处理完，显然直接返回失败不是最好的办法，至少我认为这时排队irp是更好的方法，第二个实体不需要知道错误，它只需要同步挂起，或者overlap.它会在需要时被唤醒。

到目前为止，双工driver可以利用分时方法。双句柄当然可以不用分时，但双句柄有取消IRP.的问题。

总结一下:只为一个实体提供输入输出服务的设备。1.排队不是必须的（只能一个pending,）。2.分时是比较理想的方式3.overlaped是不需要的，因为对于同一个设备句柄，即使两个线程也不能overlap.第二个调用的会返回失败重叠io正在请求中。我认为没必要花精力处理这种错误

..............bugcheck

fdo — Fri, 27 Mar 2009 08:59:00 GMT

1.用了这个语句
UCHAR** pCurret=NULL;

*pCurrent=frame[0]&0x80?pdx->pRecvH[source]:pdx->pRecvL[source];

指针的指针应该是pCurrent=frame[0]&0x80?&pdx->pRecvH[source]:&pdx->pRecvL[source];

直接kebugcheckex ..0xd1

2.AddDevice忘记初始化DPC对象了

ISR里IoRequesetDpc

直接kebugcheckex ..0xd1

终于会用windbg了

关于DDK例子

fdo — Wed, 10 Dec 2008 05:53:00 GMT

传统的ISA/EISA总线设备，虽然不支持PnP Power管理，但仍然可以用WDM结构来写，显然，中文翻译的《Programming the Microsoft Windows Driver Model》多少是有点误导了我，英文的没看不知道。

WDM或者说KMD本身是设备驱动程序编写的一个框架，或者说规矩，或者说抽象，或者说风格

如何为遗留设备编写驱动，可以参考C:\WINDDK\3790\src\general\portio，这个例子是用inf配置资源的。LogConfig段用法是关键

root是一个好东西，可以虚拟设备

另外，要对设备枚举有更好的理解，可以看C:\WINDDK\3790\src\general\toaster，这里虚拟了一个总线，好好理解总线驱动如何工作，有帮理解其他总线设备如何工作，驱动如何编写

C:\WINDDK\3790\src\general\event是driver通知app的一个例子，里面介绍了事件方式和IRP Pending方式。我写过VxD，事件方式差不多，IRP Pending是VxD没有的。应该好好理解理解！VxD的User Mode APC方式我感觉很糟糕，以后不会用了

C:\WINDDK\3790\src\general\ioctl是IRP的一个例子，IRP是个复杂的东西，我认为，我想过些日子完全弄懂了在说吧。

Windows DDK

一系列问题。。。

..............bugcheck

关于DDK例子