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.