Doron Holan - Kernel Mode Driver Framework

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

Who said Java was one of the greatest things that happened
to 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.

d

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

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

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

Good interview! 
I can't tell you how much time Doron has saved me via his valuable news group posts. 

 

hopefully we can do a screencast of the state machines to compensate for the low res shots in this video .  need to work out all the IP issues before we do that though.

d

(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

Hi Doron,

   I wanted information regarding how do i use KMDF Driver frame work to write the Smart card reader driver.

The main reason why i am asking is the Smart card API which is available takes 2 input parameters.
        
          The first parameter the pointer to the smart card extension
and the second parameter is IRP.

Now my question is how do i use these API's in KMDF driver model.
I case of KMDF model , it doesnot use IRP ..instead used WDFREQUEST....


Do we have new smart card library with the changes which caters with KMDf model ???


Thanks