DOCSEARCHbyAlgolia
Submit Docs

Driver Module Framework (DMF)

repository·master·Indexed 43 days ago

https://github.com/microsoft/dmf

An extension to the Windows Driver Framework (WDF) that enables the creation of reusable 'DMF Modules'. It provides a library of pre-built modules and a framework for developers to build and share driver logic components, featuring a Protocol-Transport interface for dynamic runtime binding of transport mechanisms like USB, I2C, or PCI.

Tokens
182.7K
Snippets
560
Records
699
Agent score
55%

What's inside DMF

  1. What is the Driver Module Framework (DMF)?

    master

    DMF is a framework for Windows device driver developers designed to implement encapsulated blocks of code called Modules. These Modules act like small, self-contained device drivers residing within a larger driver.

    Key Concepts

    • Module: A self-contained unit of code that functions like an object in an object-oriented model (possessing private data, private/public methods, a constructor, and a destructor). It can expose data structures, programming patterns, devices, or hardware buses.
    • Client Driver: A WDF (Windows Driver Framework) device driver that utilizes DMF.
    • Client: Any entity that uses a Module. A Client can be either a Client Driver or another Module (acting as a Parent Module).
    • Parent/Child Modules: A Module that instantiates another Module is a Parent Module; the instantiated Module is the Child Module.
    • Library: A collection of DMF Modules. This is distinct from a standard .lib binary file; it refers to a reusable set of Modules.

    Core Benefits

    • Code Reuse: Enables true code sharing through reusable Modules, eliminating the need to copy-paste and modify code between drivers.
    • Reduced Boilerplate: Allows developers to focus on "business logic," potentially reducing unique driver code to a tiny fraction of the total codebase.
    • Object-Oriented Patterns: Provides OOP constructs (inheritance, encapsulation) without requiring an OOP language.
    • Parallel Development: Because Modules are self-contained, multiple contributors can work on different aspects of a driver simultaneously.

  2. Overview of the DMF_UdeClient Module

    master

    The DMF_UdeClient module implements the functionality of a USB Device Emulation Extension (UDECX) client driver. It allows a client to manage the lifecycle of virtual USB devices, including creating, destroying, and plugging/unplugging them from a virtual USB Host Controller's root port.

    Key capabilities include:

    • Creating virtual USB devices with simple or complex endpoints.
    • Configuring devices to be created and plugged in automatically upon module opening.
    • Managing virtual USB 2.0 and 3.0 ports.

  3. Overview of the EyeGaze IOCTL Sample

    master

    The EyeGaze IOCTL Sample demonstrates how to create a driver that exposes a device interface allowing applications to send GAZE_DATA to a virtual Eye Gaze device.

    Key characteristics:

    • It is a basic Kernel-mode VHF (Virtual Function Driver).
    • It creates a Virtual HID Eye Gaze device.
    • It uses Kernel-mode VHF because VHF drivers can expose device interfaces and receive IOCTLs (unlike filter drivers).
    • It follows the DMF layered architecture, where the EyeGazeIoctl module can be swapped out (e.g., for a module that reads from a physical non-HID device) while keeping the Virtual HID device layer intact.

  4. Overview of Driver Module Framework (DMF)

    master

    DMF is an extension to the Windows Driver Framework (WDF) designed to help developers write WDF drivers more efficiently. It introduces a new abstraction called DMF Modules, which are WDF objects that encapsulate specific functionality.

    Key characteristics:

    • Complementary to WDF: DMF does not replace WDF; it is used alongside it. Developers continue to use WDF primitives for device driver development.
    • Code Reusability: DMF Modules allow developers to share code between different drivers. DMF also provides a library of pre-developed modules for common driver tasks.
    • Open Source: Both the framework itself and the modules written using it are released as open source.

  6. Understand VHidMini2Dmf Sample Drivers

    master

    The VHidMini2DmfK (Kernel-mode) and VHidMini2DmfU (User-mode) samples demonstrate how to write Virtual HID Mini-drivers compatible with both modes using the Driver Module Framework (DMF).

    Architecture Pattern

    These samples follow a modular design pattern:

    1. DMF_VirtualHidMini Module: Contains generic code (equivalent to the MSDN VHIDMINI2 sample).
    2. DMF_VirtualHidMiniSample Module: Contains non-generic, device-specific code. This acts as a Child Module to the generic module.
    3. DmfInterface.c: The file responsible for instantiating the DMF_VirtualHidMiniSample module.

    Best Practice: When writing your own driver, place device-specific logic in a dedicated Module that uses a generic DMF Module as a Child Module.

  7. Overview of DMF_DefaultTarget

    master
    The DMF_DefaultTarget module implements a driver pattern that streams IOCTL requests to the default WDFIOTARGET (the next driver in the stack). It automates the creation of buffers and WDFREQUESTs for both input and output data, including the necessary operations to attach those buffers to the requests. It functions similarly to the USB Continuous Reader in WDF but is compatible with any WDFIOTARGET.

  8. What is DMF_Stack and how does it work?

    master

    The DMF_Stack module implements a Last-In-First-Out (LIFO) stack using a DMF_BufferQueue.

    Clients can push allocated and filled buffers into the stack. When data is needed, clients can pop these buffers into an allocated buffer in LIFO order. This is useful for managing pending work where the most recently added item should be processed first.

  9. What is a DMF Container Driver?

    master

    A DMF Container driver is a driver that instantiates one or more Modules but does not have its own device context. Instead of managing WDF requests directly, the container driver delegates work to Modules.

    In this model, the driver's primary role is to define which Modules to add and provide callback functions (the "business logic") that the Modules trigger. This allows the majority of the driver's complexity (such as PnP notifications, device interface monitoring, and I/O request management) to be handled by the DMF Library rather than the developer.

  10. Overview of DMF_ContinuousRequestTarget

    master
    The DMF_ContinuousRequestTarget module implements a driver pattern that streams IOCTL requests to a WDFIOTARGET. It automates the creation of buffers and WDFREQUESTs for both input and output data, handling the attachment of these buffers to the requests. This module is conceptually similar to the USB Continuous Reader in WDF but is designed to work with any WDFIOTARGET.

  11. How WDF callbacks work in a DMF Module

    master

    When a Module supports WDF callbacks, DMF routes the Client Driver's WDF events to the Module.

    Key Concepts:

    • The DMFMODULE Handle: Every Module callback receives a DMFMODULE as its first parameter. This is an opaque handle used to retrieve the Module's private Context and Config data.
    • Accessing the Parent Device: To access the Client Driver's WDFDEVICE, use the DMF_ParentDeviceGet() function passing the DMFMODULE handle.
    • Isolation: A Module should assume nothing about the state of the Client Driver or other Modules. It must only act based on the parameters passed to the callback and its own private Context.
    • Full Driver Implementation: Because DMF supports nearly all WDF callbacks, it is possible (and recommended for reusability) to write an entire device driver within a Module.

  12. How DMF Modules work

    master
    A DMF Module is a WDF object created using the DMF framework. The primary purpose of these modules is to encapsulate logic that can be reused across multiple drivers. Instead of reimplementing common driver functionalities in every project, developers can leverage existing DMF Modules or create their own to be shared across their driver ecosystem.