Microsoft、Windowsドライバ開発者向けのオープンソースフレームワーク「Driver Module Framework（DMF）」を公開：Windowsドライバの開発効率と保守性を高める

DMFのアーキテクチャとは

　図1に典型的なWDFドライバの設計を示した。

図1　WDFドライバの典型的な設計（出典：Microsoft）

　図1の設計ではドライバはただ1つのデバイスコンテキストで状態を保持している。内部のユニット（BUTTONなど）間でアクセスの同期がとれないとデータの破損やデッドロックが起きる。別のドライバに一部のユニットを再利用したいとしても、ユニット間の複雑なやりとりを理解しなければならない。

　DMFを使ってWDFドライバを作成すると、このようなドライバのアーキテクチャを改良できる。

　その場合、DMFのクライアントモジュールと幾つかの構築済みの一般ユーティリティーモジュールを使ってドライバを作成する。以下では、DMFモジュールを使用するコードを「クライアントドライバ」とした。

　WDFと個々のDMFモジュールの間には薄い抽象化レイヤー（DMF）があり、これを介してモジュールがバインドされ、WDFイベントが各モジュールにディスパッチされる。図2の矢印が示すように、DMFモジュールは相互に明確に定義された方法で情報をやりとりする。クライアントドライバとも同様にやりとりする。

　全てのモジュールがデバイスコンテキストを共有するのではなく、各モジュールが固有のコンテキスト領域（図2中の緑色の部分）を使用し、自身の状態を維持する。

図2　DMFベースのWDFドライバの特徴（出典：Microsoft）

　Microsoftは、DMFベースのWDFドライバと、従来のWDFとの重要な違いを幾つか挙げている。

• 図2のように、WDFはDMFとやりとりし、DMFはドライバとやりとりする
• デバイスコンテキスト（図2中の緑の部分）は、モジュールとクライアントドライバ固有コードごとに独立して存在する。個々のデバイスコンテキストは、各モジュールに必要な要素のみを保持する。モジュールは、他のモジュールのデバイスコンテキストにアクセスできない
• WDFコールバック（図2中の赤の部分）は、モジュールとクライアント固有コードごとに独立して存在する。WDFがクライアントドライバをコールすると、DMFがそのコールを横取りし、モジュールツリー内の各モジュールにディスパッチする。各モジュールは、それぞれに適合するコールバックを処理する。最後に、DMFがそれらの各モジュールからのコールバックをクライアントドライバのコールバックへとディスパッチする
• 図2中の矢印は、モジュールとクライアント固有コード（Client Specific Code）の間のフローを示している。この例では、クライアント固有コードは3つのモジュール（ACPI、BUTTON、STREAM）のみとやりとりできる。GPIO、FIFO、LIST、THREADとはやりとりできない。さらに、ACPIはFIFOなどとやりとりできない。ソースコードを見なくても、このドライバにおけるデータフローを容易に理解できる

　Microsoftは以上のような特徴をまとめて以下のように述べている。

　「各モジュールは、自己完結的な1つのユニットだ。固有のコードと、コンテキスト、コールバックを持つ。そのおかげで、コードを簡単に再利用できる。このようにドライバを整理することで、多くの問題を解決できる」

DMFモジュールはWDFに取って代わるものではない

　DMFは、WDFの設計とやりとりのパターンに従っている。WDFに取って代わるのではなく、ドライバがOSのインタフェースに直接アクセスすることも禁じていない。

　開発者がDMFを使うメリットは、デバイスドライバが実行しなければならないタスクを、小さなユニットに簡単に分割できることだ。1つのタスクを実行するこうした自己完結的な小さいユニットを、モジュールとして作成できる。

　DMFの現行リリースには幾つかのDMFモジュールが含まれている。バッファー管理モジュールや、タスク管理モジュール、通知モジュール、各種入出力ターゲットへのアクセスモジュール、各種ユーティリティーモジュールなどだ。

　MicrosoftはDMFとDMFモジュール、テンプレート、サンプルコードを、GitHubで公開している。今後もコードの改良や新しいモジュールの追加を継続するという。