解读微软开源的驱动模块框架 DMF 已翻译 100%

杨维杰 投递于 2018/08/17 08:58 (共 17 段, 翻译完成于 08-27)
阅读 1427
收藏 0
0
加载中

The Microsoft Devices team is excited to announce the release of an open source framework for Windows driver developers — Driver Module Framework (DMF). With DMF, not only can you easily develop simple and structured Windows Driver Framework (WDF) drivers but also share code amongst your drivers.

已有 1 人翻译此段
我来翻译

Background

Over the years Surface organization developed many products such as Pro, Studio, Laptop, Book with unique, innovative hardware capabilities. To light up these capabilities, we often needed to write drivers and firmware. Even though these products had commonalities in terms of how they interfaced with the hardware, individual product teams worked in isolation and built either their own drivers from scratch or copied based on their awareness of existing code and modified to suit their needs. This did help in meeting their immediate business priorities, but led to tremendous duplication of code and maintenance overhead. Developers with varied level of experience often created many divergent solutions to solve the same problem and the code lacked structure and quality.

已有 1 人翻译此段
我来翻译

About three years ago, the team decided to take a holistic look at drivers written for various Surface products and started an effort to structure code in a way that allows for maximum reuse of code with goals to improve the efficiency, serviceability, and scalability of teams to build new products.

We started by breaking down individual functionalities in drivers into a shareable code base. This iterative effort led to the creation of DMF: an extension to WDF that provides you with a library of new WDF Objects called DMF Modules. Modules allow interaction with one another, WDF, and hardware in a structured manner.

已有 1 人翻译此段
我来翻译

Today, all WDF drivers on the team are written by using DMF. Modules are well tested and can be reused or extended later to meet new requirements. Besides having the benefit of well-architected drivers, bug fixes are now efficient. A bug fix in a Module is automatically applied to all the drivers that were built using the Module.

As part of the open source effort, we have shared many Modules that provide solutions for commonly faced problems.

已有 1 人翻译此段
我来翻译

Architecture of DMF

Let’s start by looking at a typical design of WDF driver.

In this design, the driver maintains state in a device context and the code is divided into units that access the device context and communicate among themselves. You, as the driver developer, are responsible for making sure that accesses to the device context are synchronized and strict locking hierarchy is adhered to when units communicate with each other to avoid corruption and deadlock. As WDF calls into the driver, you are also responsible for dispatching work to each of the units as needed. It is hard to know the flow of communication and keep access to the device context properly synchronized.

已有 1 人翻译此段
我来翻译

If you want to reuse for example FIFO code in another driver. You need to understand the complex interaction between the units before extracting the code and the fields used to store the state. Often times, that iserror prone.

Now let’s improve the architecture by using DMF. Here the driver is built by using a client Module and several prebuilt generic utility Modules. We are going to refer to code that uses a Module as the client driver. Between WDF and individual Modules, there is a thin arbitration layer (DMF) to bind Modules and dispatch WDF events to each Module. Now, Modules communicate with each other and the client driver in a well-defined manner as shown by the arrows. Instead of all the Modules sharing the device context, each one uses its own context area to maintain its state.

已有 1 人翻译此段
我来翻译

Here are some key differences between a traditional WDF and DMF-based WDF driver:

  • WDF communicates with DMF, while DMF communicates with the driver.

  • The device context (shown in green) exists independently in each Module and in the client driver-specific code. Each smaller device context holds only the elements that are needed for that Module. No Module can access another Module’s device context.

  • The WDF callbacks (shown in red) now exist independently in each Module and in the client-specific code. WDF calls into the client driver. DMF intercepts that call and dispatches it to each Module in the tree of instantiated Modules. Each Module handles each callback as it sees fit. Finally, DMF dispatches the callbacks to the client driver’s callbacks.

  • Finally, note the arrows. The arrows specifically show the flow among Modules and the client-specific code. In this example, client-specific code can only communicate with three Modules: ACPI, Button, and Stream. It cannot communicate with GPIO, FIFO, List, or Thread. ACPI cannot communicate with FIFO, etc. Even without looking at source code, we have a good idea of how data flows in this driver.

To summarize, each Module is a self-contained single unit. It has its own code, context, and callbacks. This makes the code easy to reuse. Organizing drivers in this way solves many problems.

已有 1 人翻译此段
我来翻译

Design of DMF Modules

DMF follows design and interaction patterns of WDF. DMF does not replace WDF nor does it restrict the driver from using OS interfaces directly. DMF makes it easier for you to break down the tasks that a device driver must perform into smaller units. Then, those smaller, self-contained units that perform a single task can be written as Modules.

1. DMF Modules use interaction patterns consistent with existing WDF objects. Just like any WDF object, a DMF Module:

  • Has a CONFIG structure, methods, and event callbacks.

  • Can be parented to other WDF objects for

    life time

    management.

2. Modules within a client driver are organized into a tree structure that is maintained by the core of DMF. The core is responsible for creating, opening, closing, and destroying Modules. In turn each Module is responsible allocating and freeing its own resources.

已有 1 人翻译此段
我来翻译

3. Modules that are siblings of each other cannot communicate directly. Only Modules in a parent-child relationship can communicate with each other; only parent Modules can communicate with their children Modules (with the exception of callbacks).

4. Modules can be extended to meet new requirements, or a new Module can be created by combining multiple Modules.

5. Module design is analogous to a class in an object-oriented programming pattern. If you are familiar with the Universal Extensible Firmware Interface (UEFI) Driver Execution Environment (DXE), you will find similarity with Modules.)

DMF Module

C++ Analogous Concept

ModuleC++ Object
Module ContextC++ Object Private Data (members). Also, importantly this is analogous to WDF drivers’ “device context”.
Module ConfigC++ Object Constructor Parameters
Module Public MethodsC++ Object Public Functions
Module Private MethodsC++ Object Private Functions
Module HandleC++ “this” pointer
Client driverThe code that instantiates the C++ object.
已有 1 人翻译此段
我来翻译

6. Each Module has its own locks. Each Module is responsible for locking its own private context. Thus, locking is granular but, at the same time, efficient and easy to understand.

7. Modules can be used by the client driver or by other Modules; are agnostic about the code that uses them.

8. Modules can use any number of child Modules. Child Modules, in turn, can use any number of Child Modules.

9. DMF provides default implementations for many driver routines such as DriverEntry, AddDevice, WDF Queue creation, so that simple driver (aka Container driver) can be created with as little code as possible.

10. The client driver only needs to instantiate the Module that the driver needs. Child Modules (if any) required are automatically instantiated by DMF on behalf of the driver.

已有 1 人翻译此段
我来翻译
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(0)

返回顶部
顶部