デバイスドライバその4
これを解決するのが、ドライバの多層化である。USBの場合でいえば、USB ControllerのベンダーはBus Driverを提供する。この上に、Function DriverがOSもしくはUSB機器ベンダーから提供される。キーボードとかマウス、といった大雑把な括りであるが、キーボードならキーボードで、操作可能な機能を提供する形だ。その上に、Filter Driverが重なり、ここで細かなカスタマイズが出来ることになる。例えば音量操作とか様々なアプリケーションランチャーといった追加キーを持つキーボードの場合、フィルタドライバの中でこれらのキーが押されたことを検出して、当該アプリケーションを呼び出すなり音量の調整を行うなりといった事が可能になるわけだ。
こうした作業を行うためには、VMSの様にドライバが自身で制御を握っていると難しいものがある。Base DriverはどんなFunction Driverから呼び出されるかは知らないし(知っていたら大変な事になる)、逆にFunction Driverも「どんな種類のドライバを呼び出すか」(USBキーボードのFunction Driverなら、USB Bus Driverを呼び出す)事は知っていても、具体的にどのドライバ(OHCIのBus Driverなのか、UHCIなのか、EHCIなのか、それとももっと別の何かなのか)までは知らないし、これまた知っていたら大変な事になる。このあたりの介在を行うために、WindowsではI/O Managerがドライバの動作に介在することになった。I/O Managerが何をするのか、という話は例えば下巻のP75(これはファイルシステムへのアクセスの例)などは判りやすい。
ただしI/O Managerが介在する時点で、かなりオーバーヘッドが増えることになるのは間違いない。特に複数のFilter Driverを実行しているケースでは、Start I/OをいちいちDevice IRQLで実施していたら無意味にIRQLが上下するだけだし、大体Filter DriverではStart I/OでIRQLを上げるというロジックそのものが不要である。実際にデバイスが動く訳ではないからだ。またFilteringの処理をDevice IRQLで行った場合、その処理中に他のDevice Interruptが入ったときに取りこぼす可能性がある。こうした事を踏まえて、WindowsのWDMではStart I/OをPassive I/Oで行うという判断がなされたのであろうし、これはリーズナブルであると思う。
一方Post ISR、VMSで言うDevice Forkに関して言えば、どのみちI/O Managerが動く時点でかなりレイテンシが増えるので、ISR→Fork→Post I/Oという形でIPLを3つも変化させなくても、ISR→DPCでもさして違いがないと判断されたのではないかと思われる。もう一つここで考慮すべき事は、VMSが動作したVAXシリーズに比べて、はるかにCPUパフォーマンスが高く、VMSほどに細かく作業を分割しなくてもDevice Interruptの取りこぼしが無いと判断された可能性があることだ。VAXというアーキテクチャは、構造はともかく性能という点ではあまり芳しくなかった。初代のVAX11-780が1 DMIPS(Dhrystone MIPSは、VAX11-780上でのスコアを基準としている)。VMS 5.2が登場した時点のハイエンド製品であるVAX9000でも50 DMIPS程度だった。対してWindows NTの開発が始まった1988年といえば、Intelのi486シリーズがそろそろ見えていた頃。性能はi486DX/33MHzで19 DMIPS程度。i486DX4-100(100MHz駆動)で45 DMIPSと殆どVAX9000並みの性能であり、更にその後にはPentiumが控えているという状況だった。こうした事を考えると、Device Forkにあたる部分を省いても実害は無いと判断されたのかもしれない。もっともこれは後知恵で、むしろi386SXとかでも何とか動くことを念頭において、極力オーバーヘッドを減らすというのが当初の動機だったのかもしれないが。
ただ、そういう違いがあるとはいえ、基本的な構造はかなりVMSから影響を受けている、ということはお分かりいただけよう。
