As promised here is an update. I'm still trying to nail down a sample hybrid driver for you all to play with. We've narrowed the contestants to two, and after the talent and judges interview portions of the show we should have a winner.So rather than let a blog post go to waste by prattling on about my dog or my signed copies of Parallel Worlds and Hyperspace, I thought it would be best served to share a "well, fancy that" moment I discovered while creating a KMDF test driver.
Synchronization scope in KMDF, the key word...scope.
See what I did (and we learn best by laughing at other's mistakes) is to set my WDF_OBJECT_ATTRIBUTES for the device object with the synchronization scope level of WdfSynchronizationScopeDevice. I had also initialized the ExecutionLevel to WdfExecutionLevelPassive thinking it would establish the execution of the object's event callback functions to passive. I then intended to establish the WDF_OBJECT_ATTRIBUTES for my queue object with the scope level of WdfSynchronizationScopeNone to ensure that I had better control over the IRQ levels in my callbacks. Sounded like a great plan to me!
A few BSODs later, I found out it doesn't quite work as I thought it would. When using the WdfSynchronizationScopeDevice as the scope level on the device object, even if I attempted to specify my queue object at the WdfSynchronizationScopeNone, the queue was inheriting the device object's synchronization scope. So everything in my queue was running at DISPATCH_LEVEL. And we all have probably found out at one time or another, some things in the kernel world don't like being called a DISPATCH_LEVEL.
So after some debugging, and then running around talking to some KMDF guys, I found the cure to my woes was to establish my device object scope level attributes to WdfSynchronizationScopeNone. I'm still also setting the execution level in the device object attributes to WdfExecutionLevelPassive, but I'm not establishing any scope on the queue object at creation, so I'm letting the natural order of synchronization objects within the callbacks manage the IRQ levels.
Thus ends my, "Why in the name of Jacques Lemaire is this thing always coming in at DISPATCH_LEVEL!?" adventure for the week. If you want some more info on this, go bug Doron. He loves when you pester him about this, really he does. >:)