在我的USB驱动里怎样获得USB底层总线驱动已经收到的数据长度？

应用程序在ReadFile时，如果usb设备并没有数据或者数据不够，也就是说，此时底层usb总线驱动并没有收到数据或着数据长度不够，那么我的驱动里处理的IRP就不会完成，一直处于PENDING状态，如果我能够在提交读取数据的URB之前先获取底层usb总线驱动缓冲中的数据长度，如果长度不够我根本就不需要提交这个urb而是直接返回，告诉应用层，读到的数据长度为0，直到长度满足应用层的要求时我才提交这个urb读取数据。但是现在有个重要的问题就是：“我如何知道底层usb总线驱动的缓冲中已经收到的数据长度呢？”

pUrb->UrbBulkOrInterruptTransfer.TransferBufferLength

应用程序在ReadFile时，如果usb设备并没有数据或者数据不够，也就是说，此时底层usb总线驱动并没有收到数据或着数据长度不够，那么我的驱动里处理的IRP就不会完成，一直处于PENDING状态，如果我能够在提交读取数据的URB之前先获取底层usb总线驱动缓冲中的数据长度，如果长度不够我根本就不需要提交这个urb而是直接返回，告诉应用层，读到的数据长度为0，直到长度满足应用层的要求时我才提交这个urb读取数据。但是现在有个重要的问题就是：“我如何知道底层usb总线驱动的缓冲中已经收到的数据长度呢？”

我明白你的意思，底层usb总线驱动的缓冲中已经收到的数据长度你是不知道的，你可以用一个线程循环收数据，并刷新收到数据的长度。当ReadFile 时你就知道目前的数据到底够不够了。

pUrb->UrbBulkOrInterruptTransfer.TransferBufferLength

这个好像在urb完成例程中才能获得吧？收据接收完以后再知道这个长度对我来说已经没什么意义了，我只是想通过一个简单的方法在读取数据之前就获得底层usb总线驱动缓冲中的数据长度，知道长度后我就可以用这个长度提交一个读取数据的urb了，要不然，在不知道长度情况下提交urb，在长度不够的情况下，我的上层应用程序可能会阻塞而不能退出，有时连重启都很困难呢。

这个长度好像只有读完数据后才能知道，所以你可以按我说的试试，这样 ReadFile 就不会一直Pending。

我觉得你可能没有采用包方式来接受数据，才会出现这样的情况！

的确是会有这个问题，cypress的驱动是这么做的。这应该是irp异步或同步启动的事。对于bulk来说，cypress的vc例子在线程里SetEvent，在主程序里WaitForSingleObject，等待读完成，然后可以再启动一次读请求，如果没有数据主程序也停住了，那么只好reset。三楼的意思可能是把启动读请求以及WaitForSingleObject都放到线程里来做，就算阻塞也不会阻塞其他的事件。按楼主想得到缓冲长度的做法似乎不可行。

我的意思是把响应AP ReadFile 与驱动从设备读数据分开，驱动一直从USB 取数据，当有 ReadFile 下来时，在驱动中可判断目前是否能满足 ReadFile 要求的数据，根据不同的情况作不同的处理，一般流类设备都这样做，如 pc camera 。我的做法不需要知道底层的缓冲长度。

理想状况是这样的：给底层usb总线驱动发个什么urb之类的东东，底层usb总线驱动就将它已经收到的数据长度告诉我，然后我再构建一个小于或等于这个长度的取数据的urb将数据取上来送给上层应用软件。
看来这种方式是实现不了啦？？？如果建立一个内核线程不断地去读usb数据放到驱动缓冲里，等上层readfile时再送给上层，这里会有几个问题的：
1、内核线程在读的时候，每次读多长？如果我的usb设备每次发送包的长度是不固定的，那么这可能会有问题。
2、增加了开销，因为驱动里要多开一个缓冲用来临时存放读来的数据。
3、内核代码难于调试和维护，不如将这个线程移到应用层，如果移到了应用层，那我的问题依然没有解决，因为这个问题已经体现到应用层去了。