新しいカーネルデザイン
otenkiで開発したnijiとrainはちょっとどうなるのか不透明なので、今後研究を進めるために新しいカーネルを設計した。
ファイルシステムがいわゆるLFSであるとか、プロトコル記述の処理系であるという特徴はnijiを引き継ぐものの、幾つか重要な変更が有る。
メッセージレベルの抽象化
nijiとrainの新規性として主張していたのはプロトコル記述の抽象化による効率的なシステム記述という点だけで、これはあまり研究室でウケず、研究にすることができなかった*1。そのため、別の新規性を模索する必要があった。
UNIXが『全てがファイル』なら、こっちは『全てがネットワーク』という感じで。
開いたファイル、TCP相手先ノード、デバイスの全てがネットワーク上のピアとして出現する。というのも、ファイルによる抽象化では時間別のイベントを表現できるとは限らないのと、UNIXのファイルはフォーマットを持たないのでアプリケーションの事後最適化が非常に困難という問題がある。これを解決するためには、全てのイベントをパケットと見做し、OS上の最優先の住人として取り扱う必要がある。
ピア一つ一つはシステム内で固有のIDを持ち、キャッシュにIPアドレスとかUSBアドレスといった通信に必要な情報を保持している。従来のOSで言えばARPキャッシュやiノードキャッシュに相当する。
また、カーネルは『マップ』を管理する。マップはピア同士の関連グラフを管理し、USBハブが削除されたときのデバイスの再帰的な削除や、Mobile IPのようなテクニックを実現する。
例えば、ファイルストリームを表わすピアは、それを実現するためのパーティションを表わすピアや、経由するUSBデバイスやハブを表わすピアと関連付けられる。これらのピアの情報は通常は独立して格納される必要が無いので、ファイルストリームのピア内に居候する形で保持されている。
TCPノードを表わすピアは、1st hopのMACアドレス、自IPアドレスのようなヘッダの作成に必要な情報全てを保持している。このような情報のコピーが発生している状況はマップを参照することで確認でき、情報は適切にアップデートできる。
プロトコル状態を保持する構造体は無限の種類が発生することになる。この問題はプロトコル記述の抽象化で解決できる。つまり、必要に応じてパケットの分解と組み立てのコードを生成することによって常に必要なアクセサが存在するようにする*2。
この場合example.comピアはEthernetからTCPまでのピアキャッシュを統合して持ち、パケット送信の際に他の構造体をコピーする必要が無い。もし、UDP通信も平行して行うような場合は、UDPとTCPを統合したピアキャッシュ構造体を新たに生成するか、IPまでのピアとしてexample.comのピアを分離し、さらにTCP:example.comのピアとUDP:example.comのピアを生成するという選択肢がある。
このモデルの重要な欠陥はマルチキャストを処理できない点にある。何らかの工夫が必要になる。
スケジューラのデザイン
通常のOSのスケジューリングが、このシステムではパケットのスケジューリングに還元できる。
いわゆるQoSの一環として、パケットの優先別キューのようなことは比較的よく行われているため、イザとなればこれはQoS技術であると言い訳をすれば研究になるように考えている。
計画
現在は、件のFPGA本のOSデザイン例として使用している。ただ、プロトコル記述言語は使用せず、構造体を静的に設計している*3。
今後はプロトコル記述言語を再構成し、より実践的な記述に絞って適用することを考えている。以前のrainはユニバーサルすぎて最適化ができなかった。
重要な競合にはPRECCS( http://preccs.isp.jp )が有るが、PRECCSは処理システムを含んでいない(C言語による記述)。
研究としてはPRECCSに対して直接的な優位性を示す方向性が考えられる。PRECCSは正規表現マッチとOSのAPIを使用したコードによりプロトコルの処理を実現するが、処理状態に応じて動的にコードを生成できる本方式が有利な点は有るかもしれない。また、PRECCSと異なり(プロトコル記述は)OS独立であるため、ストリームプロセサ等の異アーキテクチャに適応可能であることを示すという方向性も考えられる。
