OSRLogo
OSRLogoOSRLogoOSRLogo x Seminar Ad
OSRLogo
x

Everything Windows Driver Development

x
x
x
GoToHomePage xLoginx
 
 

    Sat, 21 Oct 2017     115112 members

   Login
   Join


 
 
Contents
  Online Dump Analyzer
OSR Dev Blog
The NT Insider
Downloads
ListServer / Forum
Driver Jobs
  Express Links
  · The NT Insider Digital Edition - May-June 2016 Now Available!
  · Windows 8.1 Update: VS Express Now Supported
  · HCK Client install on Windows N versions
  · There's a WDFSTRING?
  · When CAN You Call WdfIoQueueP...ously

WDF PnP/Power Interview with Microsoft's Jake Oshins

As part of our Video Update series from WinHEC 2004 in Seattle (May 2004), our own Peter Viscarola sat down with Microsoft's Jake Oshins to find out the key message he wanted driver developers to come away with about the new PnP and Power management design that Jake was instrumental in creating.  Here's the transcript from that interview:

Peter:   I'm here with Jake Oshins, the chief designer of WDF Plug and Play (PnP) and power management.  What can you tell us about WDF Plug and Play and Power Management?  What do you want people to know about the work that you have done over the last nine months?

Jake:   Previous versions that we have shown at the DDC last fall, and previous betas that people may have seen, have a very different model than the one we are showing this time [at WinHEC in May 2004].  We have given out a CD here and it is downloadable off of the web as part of our beta program.  This is a new model, one where we have replaced what we did before, with one that I think more closely matches with the primitives the driver developers are interested in.

We had a set of design goals that I thought weren’t being met by the WDF pre-releases that we had given out before.  Specifically, I’m trying to enable automatic Plug and Play and (particularly) Power Management behavior that leads to a better designed class of systems.  For instance, a mobile machine like a tablet PC or an ultra light laptop where you would really like to see all of the devices in the machine just default to off, except when they are actually being used.  When they are being used, then they are automatically transitioned back into a high power state where the driver doesn’t actually know or care that the device was in a low power state while it wasn’t being used.

We think by changing the primitives involved and by spending more time on design, we have reached something that driver developers would actually prefer to use because it abstracts enough of the complexity.  For instance, you don’t have to worry about previous state history, [and] you don’t have to decide what to do in response to particular events based on what happened in the past.  By going for better design primitives, I think we just generally simplified it.  More than anything, I am hoping that people will take a look at it and decide for themselves whether or not it actually solves their problems.

Peter:   That’s interesting.  So, you basically automated a lot of the Plug and Play and Power Management is what I hear you saying.  I’m going to ambush you with a question you didn’t expect and that is: Does this mean that because you automated a lot of stuff, as a driver writer I can’t innovate anymore, and that I can’t get to the lowest level stuff that I want to because you are doing it for me?  So, I get [PnP and power management] the Jake Oshins way or no way?  Is that how framework works now?

Jake:   No, actually.  We have learned that lesson.  As you might have noticed, we have lots mini-port models in our operating system.  We don’t really want to continue down that path.  In fact, we would really like to make sure that absolutely any behavior you need to accomplish is accomplishable.  In order to do that, we created a system where you can override absolutely anything.  You can call outside of our model.  If you choose to override and go outside our model, you take on more responsibility for the complexity in your driver.

We also spent some time thinking about how to stage the learning curve for simple drivers, particularly ones which don’t actually drive hardware. There are a lot of drivesr that are really software only.  There are filters or kernels extensions of one sort or another that are really there as a presence in kernel mode but not directly corresponding with any piece of hardware.  In our previous models, like WDM, it is often very hard to accomplish what you want to do because there is a tremendous amount of boiler plate code associated with just making these drivers work.  We tried to get rid of nearly 100% of that.  We showed earlier today in a session that a keyboard filter sample can have a total of six lines of Plug and Play and Power Management code using the current [version of] WDF.  It is our goal to make it so that additional functionality comes gradually and so that the drivers can be built up a piece at a time.  If you really need to take complete control, you can.  You can handle Plug and Play and Power Management directly if you choose to.  You can augment the behavior of the framework and you can influence by setting constraints.  Or, you can completely ignore it, if you care to.

Peter:   Sweet!  Well Jake, thanks so much for your time, I really appreciate it.

Related Articles
Who Cares? You Do! - Implementing PnP for WDM/NT V5
Converting Windows NT V4 Drivers to WDM/Win2K
Lots of New PnP and Installation Information
Special Win2K PnP Tracing and Checks
A New Interface for Driver Writing -- The Windows Driver Framework
Power Play - Power Management Changes in Vista
Write No Code...Get a GUI - Vista Power Plan Integration
Starting Out: Should You Learn WDM or WDF?
Ten Things You Need To Know About KMDF
When is a Queue not just a Queue? WDFQUEUEs

User Comments
Rate this article and give us feedback. Do you find anything missing? Share your opinion with the community!
Post Your Comment

Post Your Comments.
Print this article.
Email this article.

Writing WDF Drivers I: Core Concepts
LAB

Nashua (Amherst), NH
15-19 May 2017

Writing WDF Drivers II: Advanced Implementation Techniques
LAB

Nashua (Amherst), NH
23-26 May 2017

Kernel Debugging and Crash Analysis
LAB

Dulles (Sterling), VA
26-30 Jun 2017

Windows Internals and Software Driver Development
LAB

Nashua (Amherst), NH
24-28 Jul 2017

 
 
 
 
x
LetUsHelp
 

Need to develop a Windows file system solution?

We've got a kit for that.

Need Windows internals or kernel driver expertise?

Bring us your most challenging project - we can help!

System hangs/crashes?

We've got a special diagnostic team that's standing by.

Visit the OSR Corporate Web site for more information about how OSR can help!

 
bottom nav links