Saturday, November 6, 2010
CodeProject: Building and deploying a basic WDF Kernel Mode Driver
http://www.codeproject.com/KB/system/wdf_kmdf_basic.aspx
WDF vs WDM
There are a couple of simple state diagrams describing the transitions between the different PNP states, and between the different power states, along with the events that cause the different state transitions. On the surface, this seems simple enough. There are only 6 PNP states, and 6 system power states, so it shouldn't be that hard, right?
As soon as you start writing your driver, you realize that the more you learn about WDM, the more confused you are. Implementing PNP is doable, with the understanding that you can use someone else's cancel-safe IRP queues. Otherwise, you have to write them yourself. The real horror sets in when you try to implement power management. Typically, your device driver has to manage both the system power state policy, and the device policy IRPs. This is quite complex, and according to the documentation, you must never perform any blocking activities while handling those IRPs. This means that you have to build a complex state machine that is hooked together with the completion routines.
There is no system level synchronization between the IO, PNP, and power IRPs, so it is possible for your driver to receive both a PNP and a power IRP while it is still doing some other IO activities. The complexity this introduces is so enormous that writing this code yourself is nearly impossible if you are not an experienced, professional driver writer.
To be honest, power management was where I bailed out. My OSR USB-FX2 learning kit disappeared in a drawer, and I couldn't spend months of my free time getting the driver to work properly.
Then, WDF was released. It looked very promising. Suddenly, the prospect to write a kernel mode device driver looked exciting again. When I wrote my first device driver, there were very few articles on KMDF. The only source of information I could find were two articles at OSR Online. That's when I thought it would be a good idea to write such an article for beginners in WDF driver programming like myself.
WDF vs WDM
Background
For those of you who don't know what WDF is: it is the best invention since sliced bread. Until recently, if you needed a device driver, you had to use the Windows Driver Model (WDM). WDM provides a low level framework for creating device drivers. Using this framework, your driver had to accept PNP, Power management, and IO requests, and figure out what to do with them, based on the state of your driver.There are a couple of simple state diagrams describing the transitions between the different PNP states, and between the different power states, along with the events that cause the different state transitions. On the surface, this seems simple enough. There are only 6 PNP states, and 6 system power states, so it shouldn't be that hard, right?
As soon as you start writing your driver, you realize that the more you learn about WDM, the more confused you are. Implementing PNP is doable, with the understanding that you can use someone else's cancel-safe IRP queues. Otherwise, you have to write them yourself. The real horror sets in when you try to implement power management. Typically, your device driver has to manage both the system power state policy, and the device policy IRPs. This is quite complex, and according to the documentation, you must never perform any blocking activities while handling those IRPs. This means that you have to build a complex state machine that is hooked together with the completion routines.
There is no system level synchronization between the IO, PNP, and power IRPs, so it is possible for your driver to receive both a PNP and a power IRP while it is still doing some other IO activities. The complexity this introduces is so enormous that writing this code yourself is nearly impossible if you are not an experienced, professional driver writer.
To be honest, power management was where I bailed out. My OSR USB-FX2 learning kit disappeared in a drawer, and I couldn't spend months of my free time getting the driver to work properly.
Then, WDF was released. It looked very promising. Suddenly, the prospect to write a kernel mode device driver looked exciting again. When I wrote my first device driver, there were very few articles on KMDF. The only source of information I could find were two articles at OSR Online. That's when I thought it would be a good idea to write such an article for beginners in WDF driver programming like myself.
Subscribe to Comments [Atom]
Post a Comment