File size

File size

File size

It's hard to write kernel mode drivers. Real hard. In fact, it's hard to believe how hard it is. Well, the Windows Driver People have been working tirelessly to make it a little less hard (not easy) to write kernel mode drivers that won't hose your system.
You know, blue screen of death and the like. If you write kernel mode drivers you really should watch this video. You will be impressed with the work that has gone into the Kernel Mode Driver Framework. This framework abstracts some of the pain points away
for driver developers giving them the freedom to concentrate on their algorithms related to device usability...

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

Managed code drivers? 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 understoodwhat's going on in an operating system. Those programmersleft us a great legacy. Aaaahhh! More, more of those fairytales!!

Who said Java was one of the greatest things that happenedto the developer community?

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?)

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

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

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 .

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 . 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

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.

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

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

(1) Excellent. (2) What about hot pluggable KMDF components. (3) Loved seeing the State machines. Wonderful way you did that too d.(4) Isolation in the KMDF with garbage collection, smart pointers, COM in the kernel, etc. More Isolation and better detection will even allow maybe recovery from the KMDF BSOD. What about ring 1 and/or 2 for KMDF to achieve isolation and for debugging a
recreatable memory access.(5) Loved hearing about the serial KMDF sample. Excellent. Thank you d.

Ya know it seems like, honostly we could maintain the integrity of the device writers by using better examples ya know....Cus one of the issues that I've found as a novice user, was that even with all the fancy frameworks, there were times that certain
things required knowing how things were working on the inside.But with the drivers you know.... like in the DDK documentation..... there's a reference to functions variables... all kinds of diagrams.when it comes down to the nitty gritty of actually making
a working driver.The documentation leaves it at, well look through an example.Which is sometimes is good, but in this case, especially with the complexity of drivers. This is soooooo f#@!% up....I strongly beleive in the method of working with little peices....
get the little pieces to work, and after you put all the little pieces together the whole picture becomes clearer....But it's hard to sift through the examples in the DDK and figure out whats a little piece.It's nice to strip the example. Work with just a
little and see what it does.Seems like we could step it down a notch for beginners, and just try a hello world type driver....Just something simple like, is there anything plugged into a USB port.Then maybe if so, Then how many?Just something simple like
that..... not much just a little thing.dont worry about power, or if something got plugged in, or takin out, just what's there, and if anything, how many?And a lot of this came from the fact that I've been chewing this DDK over now for a couple months, and
I've went to the University library, and there's books on how the brains work, the body, light waves, the physics, and molecular structures of atoms and all this stuff.And you get to where the driver books would be, and there's only one shelf, about shoulder
width of old driver books for IBMsnothing with even a complete example where you could atleast do something little.and that's it....... In a day in age where so much in life almost revolves around the drivers, and only one little shelf of ancient technology.It
was really sad.Just seems like better examples would help out a lot more, than racking our brains on developing a driver framework.Ya know this driver things, really been kicking my (I need to watch my language). Use to think, that I just haven't been looking
in the right places.But here lately, I mean I have been every where, and watching this video made me realize that we're just at the threshold of technology ya know. Its just so new, and a black art like yall said.and ya just, ya know you're on your own.Cus
even out of alllllllll these resource links....... there's almost none that you can come away from as a novice, and get going with.The saddest part is...... this is only a hump..... the device development is where everythings at ya know.The local university
dont even teach a class on driver development..... its freakin crazy man

Remove this comment

Remove this thread

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.