I got looped into a discussion about the WDK glossary entry for “Windows Driver Model”. It got me thinking about how difficult it is to explain things in the driver space to non-driver folks.
When I was working in storage I used to have this problem all the time. Someone, usually a family member, would ask me what I did and I’d have to talk about what a “storage device” was, about what miniports were, etc… For a while I gave up and described my job as “something technical and utterly uninteresting”. Finally I settled on “I make the light on your hard-disk blink”.
Then I moved to the WDF team and everything became complicated again. Explaining what WDF is to a non-driver person is a bit like explaining what colors are to someone who is color blind.
So here’s my attempt to explain WDM to someone sort of technical who has no idea what a device driver does:
Windows Driver Model
An architecture for Windows extensions (device drivers) which allow the operating system core to communicate with a wide variety of devices. WDM defines a Device Driver Interface (DDI) for drivers to interact with each other and the OS, and a set of required behaviors that device drivers must implement in order to work well with the rest of the system. WDM and WDM drivers work together to provide device I/O, Plug and Play, Power Management and WMI support.
WDM is a packet-based I/O architecture. Applications (as well as the OS and other drivers) can make requests of particular devices. WDM represents these requests as I/O Request Packets (IRPs) and sends them to a particular set of device drivers for processing. The drivers typically work in a layered fashion – each performing some portion of the request then handing the request off to the next driver – until the bottom most driver programs the device to perform the requested operation(s).
Not all devices are supported by WDM drivers. Some device classes (such as storage devices or network adapters) provide their own class-specific DDIs and behaviors which represent a subset of WDM. Other drivers may be implemented using the Windows Driver Frameworks, which provides a simpler general-purpose infrastructure for writing drivers.