OS開発の今後

OS開発のマイルストーンを現代的に定義するとするなら :

1. libcをどうにかして、自分のオブジェクト環境の中でgccをコンパイルする
2. mingwのbashやm4等各種ツールを自分のオブジェクト環境の中で動かす
3. Xenの上で動くカーネルを作る
4. (Xorgを移植する)

libcをどうにかするのはそれほど難しい事ではないように思える。newlibやglibcの移植性は申し分無い。
要するに『自分のオブジェクト環境(= VFS)』のデザインが最大の関心事になる。ネットワーク透過にしたり、先進的な同期機構を実装したり、逆実行が可能であったり、ビジュアライズ手段を持っていたり、透過的な圧縮をサポートしていたりと幾らでも取り組むべき課題は有る。これらをFUSEで実現できるかは検討の余地が有る。例えばFUSEではプロセスモデルを変えることは出来ない。
個人的な見解では、もうMingw程度のPosixエミュレーションは避けられないし、そのために既存のlibcやコンパイラを使うことも避けられないように思える。多くのプログラムはC++でも書かれている。
このようにして熱心にC言語をサポートしたとしても、カーネルそのものはC言語で書く必要性は殆ど無い。プロセッサステートの管理などは非常に短いコードでXenが世話してくれる。つまり、XenをITRONのような組み込みOSや、すごいBIOSとして見てしまうという方向性とも言える。起動やスリープのような問題も同様と言える。
Xも避けられないが、Xenを使って既存のLinuxや他のOSをデバイスドライバとして使ってその辺を無視するという方向性が非常に有力といえる。たった64MBのメモリをデバイスドライバ用に使うだけで、他の数GBは好きに使える。(その目的に使えるLinuxディストリビューションを整備するのも魅力的な課題だろう)
このような目的のためにXenを使うのを進歩的でないとみなす向きも有るかもしれないが、OSデザインの進化は(誰も資本を投入しないにも関わらず)今まさに要求されている。このままではLinuxのようないわゆるOSカーネルですらBIOSに徹するだけで、アプリケーションによって高度なタスクを実現する必要が生じるように思える。PCシステムを柔軟にし続けるには新しい考察をするしかない。
それでも、ハードウェア制御のために64MBも使うのは非常識だと考えるかもしれない。しかし、これは柔軟性に対する代償で、現代的なPCハードウェアはこれだけを消費して十分なほど複雑化していると考えることもできる。