Steps in Porting
Depending on the type of driver, porting involves performing the following steps:
- Port the DriverEntry routine and add code to create the WDFDRIVER object.
- Port the AddDevice routine to an EvtDriverDeviceAdd callback, and add code to create the WDFDEVICE objects.
- Add support for interrupts if the driver supports interrupt handling.
At this point, you can perform the remaining steps incrementally and in any order, testing and debugging after each addition. For example, you can start by implementing the I/O queues and using the framework defaults for Plug and Play and power management. After you have debugged the basic I/O support, you can add support for more extensive Plug and Play and power management requests. The remaining steps are as follows:
- Add support for Plug and Play and power management.
- Add I/O support.
- Add support for DMA, if the device performs DMA.†
- Port WMI code.†
- Port code to handle requests that the framework does not handle on behalf of KMDF drivers.†
- Revise the INF that installs the driver.
† This functionality is only available to Kernel-Mode Driver Framework (KMDF) drivers.
Except as noted, the information in this section applies to all types of drivers (PDO, FDO, and filter DO). However, if you are porting a bus driver (PDO) to KMDF, you will also need to port the device enumeration code. For information about enumerating devices, see Enumerating the Devices on a Bus.
For reference information describing the ways that the various WDF objects, methods, and event callback functions map to common WDM objects and functions, see Summary of KMDF and WDM Equivalents.
Feedback
https://aka.ms/ContentUserFeedback.
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see:Submit and view feedback for