Doron Holan - Kernel Mode Driver Framework | Going Deep

pierreleclercq

Good interview. And why use the word complicated so many
times? For sure developing a kernel mode driver is not easy,
but the speaker had a clear voice. Also I'd be cautious about
those "write those 1000's lines of code in 5 minutes, and that
will only be a couple lines now". Still the formalization into a state
machine is interesting. Also I appreciated when the speaker said
they're trying to be consistent. Good tools do not try to do your
work, they help you do good work.
How do the mini-drivers fit into this? Are they simply outdated?

Managed code drivers? Sad

Ark! One day will come when we'll
spend long winter evenings around the fireplace, telling our
great-great-grand-children (thanks to bio-engineering) odd stories.
A long time ago, there were people who actually understood
what's going on in an operating system. Those programmers
left us a great legacy. Aaaahhh! More, more of those fairy
tales!! Wink

Who said Java was one of the greatest things that happened
to the developer community? Perplexed

Massif
aim stupidly high, expect to fail often.

Awesome stuff - as someone who used WinDriver to develop kernel mode drivers I'm happy that MS have provided the same sort of framework for driver development. Although it sounds more far more complete and more useful.

Now if only a really good, and easy to setup set of Debug tools could be developed - I'd be a really happy bunny. (Windbg and softice are good, but surely it can be made easier?)

GandalfWhite
Gandalf White

Damn cool video. Doron, your voice and clarity of expression is too good.
Liked the way you have taken care to name methods & objects (get/retrieve & set/assign) - Only a developer can understand these kind of issues Smiley

Waiting eagerly for the screencast of those wonderful state machines....

doronh

pierre: I guess charles could have used a synonym for complicated, but in the end, writing a driver is complicated. Unlike a user mode application where preemption doesn't happen that often on a UP machine, a driver can easily get preempted on the same thread. You have to think about synchronization all the time in every context...it's a tough thing to do...and the consequences are harsh Embarassed .

Yes, it sounds crazy that 1000s of lines of code go away, but they do. WDM had a ton of state changes which implied many similar actions. KMDF formalized it and broke it down into actions w/only one purpose. this makes the code much more compact.

massif: i have not heard good things about windriver, so i am glad we can meet a need in that space. Debugability is important to our team. The debugger team is a separate team from us (in a different org as well), so getting huge changes into the debugger is a bit hard. We took the route of making a very extensive debugger extension (Wdfkd.dll) to make debugging easier.

Gandalf: yeah, the naming thing is totally geek Tongue Out . You only appreciate once you have been bitten by inconsistent naming in the past. I'm glad someone else appreciates it. Hopefully we can do the screencast soon, right now getting vista out the door takes up alot of my time Big Smile

doronh

as for mini-drivers, i assume you mean drivers that fit into a port/miniport model like NDIS or SCSIPORT. Those stay the same for now, but you won't likely see new port driver models that are not KMDF based. KMDF fits into some existing models today as well. For instance you can easily write an NDIS-WDM driver using KMDF to do all the WDM aspects.

d

pierreleclercq

> "I guess charles could have used a synonym for complicated"

Nothing wrong with Charles, I was speaking of the overall video
and associated posts.

When complexity gets high, it becomes a requirement to
formalize and structure well. In this sense the framework
described sounds like a good help. On the other hand, it is
expected from someone working on low-level device drivers to
have the ability to deal with complexity. Still, it is always a good
idea to write frameworks that lean naturally to good design
and coding practices.

BuckyBit

now this is a video I really would have liked in HD-quality, at least the first part Wink

Thanks for another deeply appreciated gem. You almost make me want to 'like' writing drivers for win again...and thanks, doronh, for making me feel old (c/c++, assembler...) but expensive;)