OS開発の今後の今後
2画面分くらいの長文を書いたけど編集画面の横のメニューに触って消してしまったので要点だけ。。
# はてなの自動バックアップはいつになったら帰ってくるんだろう
API or Language(なぜAPIでなくてファイルシステムなのか)
個人的には、究極に効率的なシステムのためにも、APIを決めることよりも「記述環境」を作ることに意義が有ると考えている。
システムとして出荷されたときのバイナリサイズよりも、実行時に占めるメモリサイズのほうが多分重要で、そのためには必要な部分だけをロードするといった対策が必要になる。出荷されたときのバイナリサイズにしても、部品の共通化を進めるのは良い影響を与える。
(少なくとも、僕の知識ではAPIコールの効率性とシステムの効率性を関連付けられない)
そもそも、現代的なシステムではプログラムよりもデータの方が圧倒的に大きな存在感を占めている。メモリからキャッシュへのコピー、データの配列、そのほかのI/Oがシステムの速度を決定付けている。
(もし必要なら、)良くデザインされたファイルシステムはこの側面にアプローチできる。
ただ僕の主張としてより重要なのは、APIはプログラマにしか触れないけれどファイルシステムはユーザ全員が触るという点で、より端的に表現すれば「多くのプログラミングは本来プログラムの外部で行われる必要が有る」。
一つ一つのプログラムを小さくすることよりも、プログラムの数そのものを減らした方が効率的に思える。
プロセスモデル変更の必要性(OSを書く必要性)
ユーザモードで実現できないことが2,3存在する。
- 個々のPUへのスケジューリング
- リアルタイムかつ動的なメモリ管理
- QoS
- 省電力
- セキュリティ
Linux(カーネル)を改良して実現できる？ Yes。
しかし、Linuxのネットワークスタック/スケジューラ/...を改良するよりも、LinuxはI/Oサブシステムに注力させた方が早い(はず)。
例えばシステムの時刻管理といったタスクを置き換えるのはそれほど簡単な作業ではない。
現実的な回避策と今後
もっとも、今やっている研究ではLinuxを使っている。
外部プロセッサの制御をLinuxから奪って専用のカーネルモジュールを充てた上で自前のTCPスタックを動かすということをしているので、このようなケースに自分でカーネルから作るのは正しくない。
他にも、KORGのOASYSといったシンセサイザやいくつかのアーケードゲーム基板のように、特定アプリケーションに特化した用途であればLinuxを独自に調整することで望む結果が得られるという実例は非常に多い。これは現実的な回避策として機能している。
しかし、従来カーネルの改良によって実現していた研究が、今後はより自由なカーネルの自作によって可能になる可能性があるという点が重要といえる。この様な研究は、従来「自分の良く知っているハードウェア」だけを対象に行われていた(つまり、大学で言えばSPARCstationとか)。これがXenのようなHypervisorとそれを支援するCPUの普及のおかげで一般的なハードウェアを対象に行えるように変化している。
Linuxカーネルの改造が面倒＆アプリケーションの移植が面倒だからという理由で行われていない研究ジャンルは必ず有るはずで、そこをカバーすることが今後の(PC向けの)OS開発の方針として主流を占めると考えている。
もっと纏めると、時代のゆり戻しが起きている。
従来、ハードウェアは固定され、ソフトウェアとは分離不能であった(あるいは存在しなかった)から、多くのカーネル(やアーキテクチャ拡張の)研究が存在した。それが、PCという非常に普及したハードウェアで駆逐されて、多くのシステムプログラミングはUNIX(やWindows、DirectX...)の活用法になった。それがさらにHypervisorによってハードウェアが『透明』になりつつあるのが現在で、システム研究は新しいフェーズに入っている。
もっとも、Hypervisorが抽象化するのは基本的に*1ハードウェアだけなので、コンパイラや他のツールを抽象化する努力は依然必要となる。
