As I've mentioned in my previous posts, Microsoft is trying to simplify the development of windows device driver by changing the corresponding driver framework. Therefore, WDM (Windows Driver Model), which is the old framework will gradually be replaced by WDF (Windows Driver Foundation). WDF can be further subdivided into 2 frameworks: the Kernel-Mode Driver Framework (KMDF), which allows the development of kernel-mode drivers, and the User-Mode Driver Framework (UMDF), which allows the development of user-mode drivers. Actually, WDF and its frameworks build on top of WDM and provide abstractions that are easier to understand and implement. Therefore, even though it'll be possible to continue writing WDM drivers (Microsoft has never up to now prohibited the creation of drivers using any of the legacy Windows NT driver technologies), it'll be much easier and safer to use WDF.
Since windows drivers will be created either by KMDF or UMDF, in this post I'll just try to provide some (theoritical) posts that provide introductory information for WDF. I'll write different posts that provide information on how to develop drivers using KMDF and UMDF. So, the first place to look at should be http://www.microsoft.com/whdc/driver/wdf/default.mspx and especially the following documents:
Based on the second link (the WinHEC presentation), I would like to show an array that shows both the current driver models and the future (at least in Windows Vista) for different device/driver classes:
Most of the first 8 models in this array (eg NDIS, SCSIport, etc) follow the port-miniport model. The idea behind this model is that instead of having to write a whole WDM driver, Microsoft provides a driver (i.e. the "port") that covers all the functionality that is common between the devices of the same class. The driver writer just needs to write a small "plug-in" (i.e. the "miniport") that communicates with the port and takes care of the rest of the functionality that depends solely on the actual device. Of course, it's possible for a driver developer to write a WDM network driver, instead of relying on NDIS, but this would just be a lot more work for the same result.
What about filesystem drivers (not filters)? Are there plans for easy-to-write, user-mode filesystem drivers, comparable to the FUSE framework on Linux and FreeBSD?
There are some plans for user-mode file-system drivers, so we'll be able to see them in the future, however this will definately take some time.
I would like to know about user mode file system dirvers/filters. Will it be avaliable?
I think that Microsoft is showing a turn towards user-mode drivers, since they're easier to develop/debug/maintain and they're also more secure and isolated. However, it's not feasible to port every driver type from kernel-mode to user-mode tomorrow (or generally in the short time frame). For example file system drivers /filters and the display drivers belong to the category of "difficult to port to user-mode", not only because of architecture issues, but also because of performance. Also, as I wrote in my post the (initial) version of Vista has already defined driver models, which are the ones specified in the post. So, the summary is that we'll see them, but not in the near future.
Thank you very much for the answer. Even if it's not for the near future, I'm looking forward to it.
Our product current has several kernel drivers - file system drivers, process monitors, network redirectors, etc. As a result, when we install our product, we require a reboot. For Longhorn certification, we need to eliminate reboots. Will converting the drivers to KMDF or mini-filter drivers solve the problem?
I have no sound and do not know turn it back on it said i need Sound device& mixer devices
STORport, ATAport needs to removed from that XP column. And AVStream drivers of most of my devices always produce BSoDs and are bloated. They need to be moved to WDF.
i'm porting driver codes(pci) of wdm to kmdf for windows 7 but wdm involved dispatch functions, so can i port them to kmdf?