Look Ma, I’m on Channel 9!

I was interviewed for channel 9 a couple of weeks ago, you see the interview here.  We talked about KMDF, the state machines and the future of driver development.  I had a great time doing the interview, hopefully you like it as well.  Please let me know if you want me to do another interview (and if so, what topics you would like me to talk about).

Comments (5)

  1. hanzhu says:

    I’m intereasted in the topic about the history and the evolution of the DDK DDI from NT4 to Vista. And you may introduce the drive force behind the evolution. One more question: is there any opportunity for Microsoft to make the source code of KMDF public?

  2. nksingh says:

    Nice video…  scary state machine.  I’m betting it’s not as bad as it looks because in a normal driver some of those states would blend together whereas they have to be seperated for the KMDF since you need to call driver callbacks along the way.  

    Does KMDF also sit on the I/O path?  Would a high-speed storage driver, for instance, be well served by KMDF (assuming one has got some brand new storage model which does not fit under the storport)?

    Thanks for doing this…  I’d look forward to seeing you on C9 in the future!


  3. neeraj, yes, the state machine looks a little more complex then a sample WDM driver because we use the state machine to track the actual state in KMDF.  Outside of the current state, there are no other state tracking variables.  To add additional state, logic, or decisions (based on callback return values, irp completion, etc) we add more states to the machine.  On the other hand, a std WDM driver maintains a bunch of different states (pnp state, power state, i/o state, etc) in variables in its extension and implements an informal state machine based on the union of those states.  Finally, when 2 state machines interact, they do so by sending a message between each other, so to process the answer, you have a waiting state which will process the answer message.  What it boils down to is a lot of states, but each state only does one thing and is very simple.

    Yes, KMDF has WDFQUEUEs and is definitely in the I/O path.  that is part of the model in that you can aggressively power down the device while the system is running and KMDF can power it up when new I/O shows up.  Now, if you are concerned with making fwd progress (like always being able to process paging I/O regardless of available system resources), KMDF is not quite there yet.  If you can tolerate this limitation, KMDF is a great avenue to investigate.

  4. Max says:

    Thanks for the video, it was really interesting and KMDF looks like a great project: I wonder if you could do a future blog entry talking about the challenges of having Visual Studio intergration for kernel-mode drivers, that you touched on in the interview?

    Thanks again!


  5. Max, that’s a good suggestion.  I will put it on the to do list of things I want to write about.


Skip to main content