デバイスドライバその3
Start I/O Routineの起動後は、再びIPL=0に戻り、User Applocationが処理を再開することになる。さて、I/Oが終了すると、デバイスは再びDevice Interruptを発行。これにあわせてドライバ内のISRが起動することになる。このISRの中で行うのは、原則としてDevice Statusの内容をローカルキューにコピーし、直ぐにForkを行う。このForkというのはVMS独特の用語で、意味合い的にはUNIX系のForkの逆の意味である。UNIX系のForkの場合、親プロセスから子プロセスが生成されるもので、「熊手(Fork)」の柄から先端に進むイメージである。つまり1つのプロセスから複数の子プロセスに分離する様が、熊手の様に見えるという話だ。一方VMSはというと、複数のIPLで動くドライバの処理が最終的に1つに収束するという意味合いであり、逆に熊手の先端から柄に収束してゆくイメージと考えれば良い。具体的に言えば、Device Forkという処理により、Device Statusを保存して直ぐ次のStart I/O Routineを開始することが出来る。これにより、連続的にI/Oを行うシーンで無駄にI/Oの開始を遅らせない事が可能になっている。
さて、Start I/O Routineが動かない場合、IPLはDevice Forkレベルに維持される。厳密に言えば、ISRが終了した時点でForkのQueueをチェックし、そこにエントリがキューイングされているとIPLをForkレベルに設定される。この中でVMS Kernelは、先ほど保存したDevice StatusをIRPにコピーし、次いでDriverのPost ISR Routineのキューイングを行う。これが一段落すると、次にIPLはI/O Post ISRに変わり、ここでやっとドライバのPost ISRルーチンが動作することになる。ここで各デバイスのPost I/O Processが動作するわけだが、User Applicationの中にはI/O完了処理を非同期ルーチンで行おうとしているものもある。これらはSYS$QIOへのパラメータという形でIRPに含まれているので、これがある場合はPost ISR Routine内からその処理ルーチンをAST(Asynchronous System Tram)というレベルでやはりキューイングする形になる。全てのPost ISR Routinの処理が終わると、次にIPLはAST Delivery ISR(＝2)に変わり、やっとユーザーアプリケーションの非同期ルーチンがこのIPL=2の環境で動作。これらが全て終わるとIPL=0まで落ち、再びユーザーアプリケーションの処理が再開されるという仕組みだ。
さて、このあたりの仕組みを見ると、両者が実に良く似ていることが判る。大きな違いはStart I/O RoutineをDevice IRQL(=Device IPL)で発行するかどうか、という程度で、それ以外の構造は非常に良く似ていることが判る。特に、I/O命令の詳細を取り扱う構造体がIRPという名称が付いているあたりは、間違いなくVMSから概念を持ってきたものと想像される。
勿論概念や名前はともかく、IRPの構造そのものはまるで異なっている。特にWindowsの場合、WMIでドライバの概念が大幅に拡張された関係で、VMSでは想定もしていなかったニーズが多く、これらをサポートするためにかなり複雑化しているのが特徴だ。VMSのドライバとWindowsのドライバ(特にWDM)との大きな違いは、多層ドライバの概念が追加されたことだろう。このあたりは下巻P72以降に詳しいが、要するにVMSとかWDM登場以前のWindowsのドライバとは、そのデバイスの全てのI/O要求を一つのドライバでハンドリングすることを念頭に置いた設計になっており、また原則として1デバイス＝1ドライバの関係を保っていた。原則、というのは希に1つのボードに複数のデバイスが載った製品とかがあり、これを扱うためにはドライバにちょっと変則的な細工をする必要があったためだが、こうしたものはやはり「例外」扱いだった。ところがデバイスの多様化が進むにつれ、こうした仕組みでは困難になるケースが登場したためだ。
その代表例がUSBであろう。今はOHCI(USB 1.1)/EHCI(USB 2.0)で事実上統一されているが、当初はOHCI以外にUHCIというデバイスも広く使われており、しかもOHCIなりUHCIの先に何が繋がるか、に関しては非常に柔軟性があった。キーボード/マウスはもとより、スピーカーやスキャナ/プリンタ/光学ドライブ/カメラ/マイク/etc...と、非常に幅広い範囲でのデバイスに対し、Plug & Play環境を実現できることが求められていた。こうなってくると、一つのドライバで全部をカバーするのは到底不可能である。これらの周辺機器を全て網羅する、たった1つのドライバなんてものは誰にも作れないし、作ったところで新製品が出たらもう使えなくなる。大体こうなってくると、USB機器のベンダーとUSB Controllerのベンダーのどちらがドライバを提供するかも問題になるだろう。(続く)
