Yes, they are.
No, this is not correct, if you mean to say that an asynchronous request from user-mode will be serviced asynchronously by the kernel driver.
Let’s talk WDM for a moment here, to avoid all confusion: If the driver gets an async request directly from user-mode (that is, a ReadFile sent with an overlapped structure), and if that driver then blocks in its dispatch routine… the calling thread will wait. This thread is not getting ascychronous service.
There are three cases, right?
- App requests async processing, driver provides async processing. Result at app: ASYNC.
- App requests sync processing, driver provides async processing. Result at app: SYNC.
- App requests async processing, driver provides sync processing. Result at app: SYNC.
It can’t be any other way.
Now… if you consider how WDF makes this LOOK, the situation seems much easier. Because WDF places its WDFQUEUES ahead of the EvtIoXxx Event Processing Callbacks – this is VERY different to WDM where the driver is called in its dispatch entry point and responsible for doing something with the request (queue it or immediately process it).
Peter
OSR
@OSRDrivers