My driver uses a lot of DPCs to do the work of dispatch calls for the reason that the device operates on a specific processor's internal registers. Setting the target processor for the DPC ensures that it runs on that processor.
To avoid details, I'll just say that I'm having some synchronization problems between the IRP dispatch, the DPCs, and some work items that are necessary to do some IRP processing back at PASSIVE_LEVEL after the DPC has finished.
As an alternative, I've thought of having a worker thread, pinned to the processor, do all the work at PASSIVE_LEVEL, using some sort of work queue to communicate with the IRP dispatch methods. And if the IRP is being called by a user thread that is also pinned to the same processor (which in my driver's case would be a typical situation), then it could just do the work itself and avoid context switches.
There is a complication, though. The behavior of the hardware involves interrupts and an ISR. Could the ISR simply signal some event and a worker thread could be waiting for it? I believe that KeSetEvent is OK at DIRQL as long as Wait = FALSE. Is this so??
Or is there some reason why an ISR should use a DpcForIsr?
In short, I have three kinds of operations the driver will perform (other than the ISR), and these can be serialized easily enough:
1. Handling an IRP in the same thread that called it, when that thread is pinned to the same processor.
2. Handling an IRP in a worker thread on behalf of the thread that called the IRP.
3. Servicing an interrupt in the hardware, in a worker thread.
It looks like you're new here. If you want to get involved, click one of these buttons!
|Upcoming OSR Seminars|
|Developing Minifilters||29 July 2019||OSR Seminar Space|
|Writing WDF Drivers||23 Sept 2019||OSR Seminar Space|
|Kernel Debugging||21 Oct 2019||OSR Seminar Space|
|Internals & Software Drivers||18 Nov 2019||Dulles, VA|