1. Differences between KMDF and WDM Samples
The
KMDF samples are based on the similarly named Windows Driver Model
(WDM) samples that are provided in the Windows Driver Kit (WDK). With a
few exceptions, the corresponding drivers support similar features. If
you are experienced with WDM, you might find useful a comparison of the
KMDF and WDM samples.
The primary difference between the samples is that
the KMDF samples are much shorter and less complex. The reason is that
KMDF implements most of the details of WMD, so that you can avoid
writing many lines of code that perform common tasks and implement
common features required in all drivers. Instead, you define callbacks
for the conditions and events that your driver must handle.
For example, KMDF driver, like WDM drivers, support
Plug and Play and power management for their devices. WDM drivers
typically include thousands of lines of code to ensure that they handle
every possible state and minor I/O request packet (IRP) code; drivers
often require code to handle IRPs that they don’t even support. A KMDF
driver, however, includes code to handle only those features and
requests that its device supports. All other Plug and Play and power
requests are handled by WDF in a default manner. These defaults make
possible the incremental development of KMDF drivers. You can implement
a skeletal set of features, test the implementation, and then
incrementally add code to support additional features or perform more
complicated tasks.
In a practical sense, the most significant
difference between KMDF and WDM drivers is the number and complexity of
the required functions. For an example of this difference, compare the
simplest form of the WDM Toaster sample
(src/general/toaster/func/Incomplete1 in the WDK installation
directory) with the simplest KMDF Toaster sample
(src/kmdf/toaster/func/simple in the WDF installation directory).
Both drivers support basic Plug and Play, power, and
WMI requests. The KMDF sample also includes stub functions to handle
read, write, and IOCTL requests. However, the KMDF sample contains many
fewer lines of code than the WDM sample. Table 1 compares the functions in these two drivers.
Table 1. Comparison of a KMDF Simple Toaster and WDM incomplete1 Toaster Samples
| WDM Function | Equivalent KMDF Function | Comments |
|---|
| DriverEntry | DriverEntry | Function has same prototype. KMDF driver creates WDF driver object. |
| ToasterAddDevice | ToasterEvtDeviceAdd | KMDF driver creates a default queue for I/O requests. |
| ToasterUnload | None | KMDF driver uses defaults. |
| ToasterDispatchPnP | None | KMDF driver uses defaults. |
| ToasterSendIrpSynchronously | None | WDM driver passes IRPs down the stack to be completed synchronously. KMDF driver uses defaults. |
| ToasterDispatchPnPComplete | None | KMDF driver uses defaults. |
| ToasterDispatchPower | None | KMDF driver uses defaults. |
| Toaster System Control | None | WDM function passes WMI IRPs to the next lower driver. KMDF driver uses defaults. |
| None | ToasterEvtIoRead | WDM function handles and completes read request. KMDF function is a stub. |
| None | ToasterEvtIoWrite | WDM function handles and completes write requests. KMDF function is a stub. |
| None | ToasterEvtIoDeviceControl | WDM function handles and completes device I/O control request. KMDF function is a stub. |
2. Macros Used in KMDF Samples
Many of the KMDF samples use two macros that might be unfamiliar:
PAGED_CODE
UNREFERENCED_PARAMETER
The PAGED_CODE macro causes the driver to assert if the function is called at IRQL DISPATCH_LEVEL or higher. The macro is defined in ntddk.h and takes no arguments. It works only in a checked build.
The UNREFERENCED_PARAMETER is defined in the standard WDK header file ntdef.h, which is included by ntddk.h. It disables compiler warnings about unreferenced parameters. It can be used in any Kernel Mode Driver.
