Plan9NotDeadYet

Plan9NotDeadYet

プレゼンテーション

Plan 9、いまだ死なず。そして、それから何を学ぶことができるか

Ron Minnich

Advanced Computing Lab

Los Alamos National Lab

LA-UR-05-4132

(オリジナルはhttp://www.cs.unm.edu/~fastos/05meeting/PLAN9NOTDEADYET.pdf

Unix

  • シンプルな、バイトストリームのopen/read/write/close。
  • 資源にはパスによる名前がついている。
  • とても先進的なコンセプトで、Windows NTでもまだやってない。(そのうち"ls \devices"ってやってごらん)
  • また、とても論争を呼んでもいた

二人の男と一台のコンピュータ

f:id:oraccha:20081019062014j:image

初期のUnix

f:id:oraccha:20081020223433p:image

Unixカーネルシステムコール

  • パス名
    • chdir, chmod, chown, creat, exec, link, mknod, mount, open, stat, umount, unlink
  • ファイル記述子(FD)
    • dup, fstat, gtty, stty, seek, read, write, open, close
  • パラメータなし、または出力のみ
    • fork, getgid, getpid, getuid, pipe, wait, time, times
  • プロセスID(PID)
    • kill, signal
  • その他
    • break, csw, nice, profil, ptrace, setgid, setuid, stime

つまり、Unixでは「すべてがファイル」

  • もしくは、そう考えていた
  • わりと早くそのモデルが壊れてしまうまでは
  • 我々が遭遇したのはこれを使っていたときだ:
  • (写真がない)
  • DEC DAC

DEC DAC問題

  • 問題:DAC (/dev/dac)を読もうとしている
  • OK、それはファイルだ
  • その代わりに、プロセスが何か他のもの、例えばフィルタから読み込むとしよう。...ファイルを開く...おや、ちょっと待て...IPCには名前がないじゃないか
  • kill()はIPC機構の一つで、パイプはもう一つのものだ。どちらにも名前がないことを思い出そう

当時はそれほどうぬぼれていなかった

  • 「すべてがファイル」モデルはわりと早く壊れ始めていた
  • そして、それはとても重要な使い方に対するものだった
    • ファイルを取り、フィルタを適用し、結果をファイルとしてユーザに示す
    • これができない!
  • そして、事態はさらに悪くなった...

こん畜生!

  • すべてのものに名前があるって言った?
  • ごめん、嘘ついた
  • 名前がないもの:
    • プロセス
    • ファイル記述子
  • これらはその後直されたことに注意
  • 直されてないものは何

壊れ始めたとき

  • Unixモデルは異なる種類の資源に対する共通のアクセス方法を持っていた
  • 例えば、"/etc/passwd"と"/dev/dk0"はどちらもパス名
  • しかし、異なる種類のものに行き着く
  • つまり、一つのインタフェース、複数の資源
  • 1970年代後半、Unixは壊れ始めた
  • その原因はネットワーキングだった

Unixへのネットワーキングの追加

  • 最初はこんなことを考えていた
    • "/dev/tcp/harv" (RAND RFC 618)
    • 一つのインタフェース、複数の資源
    • 失敗した。いくつかの原因のせいで
    • 当時のUnixはファイル名からプロトコルストリームへ切り替える手段を(アーキテクチャ的に)持っていなかった
  • そして、ソケットに対するバイナリ名が作られた(BBNによって?よくわからない)
  • それは完全にモデルを壊した

Unixの何が変わり始めたのか (1978)

f:id:oraccha:20081020223439p:image

その後...さらなるインタフェースの追加

f:id:oraccha:20081020223438p:image

何が起きたのか振り返る

  • 互換性のない新しいサブシステム
  • 複数のインタフェース、複数の資源
    • 似たような手続きに対する重複した機能
    • カーネルの基本的な一貫性は崩壊し始めた
  • パス名モデルは完全に壊れた
    • 「とても先進的なコンセプトで、Windows NTでもまだやってない。(そのうち"ls \devices"ってやってごらん)」
    • ちょっと待った、Unixも同じじゃん! 今ではすべての種類の資源がパス名を持つとは限らない

そして、今まで

  • 月日が流れ、消え去ってしまうべきレガシーな機構が残っている
  • 基本的な入力モデルはいまだにtty
  • そんなの信じないって? xtermで'stty'って入力してごらん。なんでウィンドウがボーレートをもってるの
  • 同じく、なんでxtermでテキストを編集できないの

xtermウィンドウ

f:id:oraccha:20081020223434p:image

  • ワオ、どんだけ先進的
  • 性能が1,000,000倍になろうとも、中間にはASR-33が鎮座している

我々はどこにいるのか

  • 300を超えるシステムコールが、Linuxにはある
  • 大半は異なるサブシステムへの異なる種類の入り口だ。ソケットから始まった傾向が続いている
  • カーネルの層化は、更新されるたびに、ますます複雑になっていった

何がまちがいだったのか?

  • Unixはアクティブプロセスモデルを持っていた
  • そしてパッシブデータモデルも
  • でも、アクティブデータモデルを欠いていた
    • Farberは1978年にそのことを指摘したが、われわれのすべてがナンセンスだと思った
    • 彼はいつも正しかった
  • また、資源を名付けるための構造の豊富さに欠けていた
  • そしていくつかは単にまちがっていた

そして、さらに

f:id:oraccha:20081020223440p:image

よりよいモデル

f:id:oraccha:20081020223437p:image

共通のサーバインタフェースを持ち、サーバの位置はもはや重要ではない。キャラクタ/ブロックデバイスの区別は時代遅れ。プロセスはもはやサーバとデバイスを区別しない。デバイスはもはや番号を持たない。

f:id:oraccha:20081020223435p:image

注意:ローカルデバイスのファイルシステム上にあるemailファイルシステム。どの要素もリモートに置くことができる。

キーとなるアイデア

  • Unixカーネルは「I/O多重化装置」である
  • この新しいカーネルは「サーバ多重化装置」である
    • プロセスからサーバへのアクセスを仲介する
    • サーバは大抵プロセスであることに注意
    • emailの例で示したように、再帰的
  • そして、デバイスは単にプログラムに対するサーバのようにみえる
  • すべての資源に対する単一のインタフェース
  • すべてのサーバに対する標準プロトコル(9p2000)

アクティブデータモデルと名前付き資源

f:id:oraccha:20081020223432p:image

  • もはやデータはOSによって操作されない
  • OSはプロセスからサーバへの通信仲介者に専念する
  • OSは直接データを操作しない

このモデルの利点

  • プロセスがサーバと会話する
  • サーバは何たり得るか?
    • 一つのものに対する、ファイルシステム
    • もしくは複数のファイルシステムをたばねるファイルシステム
      • MirtchovskiのResourceFS(9grid向けに開発)
    • もしくはディスクのようなデバイス
    • もしくはグリッドスケジューラ
    • もしくはグラフィックデバイス
    • もしくはセキュリティシステム

境界はそれほど重要じゃない

  • 自分のノードにある「ファイルシステム」か、それともどこか別の場所にあるのか?
  • このモデルでは、それほど気にしない
    • それを好きな場所に置くことができる
    • だから、Barneyにたたきのめされることもなくなる
  • OSが通信手段を提供するので、ローカルの要素に対してでも、ネットワークを介してリモートの要素に対しても同じように通信できる
  • アプリケーションからは同じ資源の集合が見える

これを実装したシステムがあるのか?

  • はい、そのシステムの名はPlan 9
    • フロム ベルラボ
  • 第4版が2002年にリリースされたところ
  • 2003年6月に、オープンソースリリースパーティが開かれた
    • DOEの援助があった

Plan 9とは何か

  • あなたが見たことのある何かとは違う
    • ミニ/マイクロ/ナノ、または他の流行りの○○カーネルではない
  • コアOSは、「デバイス」の静的に設定された集合である
    • これは「OSの中に持つものは何か」を意味する
    • 例えば、メモリやネットワークハードウェアなど
  • その他すべては「サーバ」である
    • ファイルシステム、ウィンドウシステムなど

(いくつかの)Plan 9の特徴

  • 固定アーキテクチャの小さなカーネル
    • HPCノード向き
    • カーネル内デバイス(例えば、メモリ、NICTCP
    • カーネル外サービス(例えば、TCP、ファイルシステム)
  • はい、はい、本当に、同じ機能のサーバをカーネルの中にも外にも置くことができるのです
  • デバイスは、最初にサーバとしてプロトタイプすることができる。
    • これが実装の一つの手段になる。例えば、Portals
  • 実時間スケジューラ
  • 簡潔で速い

Plan 9の構造

f:id:oraccha:20081020223436p:image

  • プロセスは必要に応じてサーバに接続(attach)する
  • 接続は継承される
  • グループの外からは見えない
  • この例では、あるグループはリモートファイルに接続している
  • 別のグループでは、他にサービスを持たないのでIPCだけを必要とする

Plan 9のシステムコール(BG/Lの"LWK"の半分未満)

  • パス
    • bind(ネットワーキングとは関係ない), chdir, exec, mount, open, create, remote, unmount, exec, remove
    • notify(シグナルだけど、不定長バイト文字列を持つ)
  • FD
    • close, dup, fsession, fauth, fstat, seek, stat, wstat(例えば、chmod), pread, pwrite, fd2path
  • その他
    • rfork, alarm, exits, noted, rendezvous
    • segattach, segdetach, segfree, segflush

議論

  • ディスクはどのように見えるのか
    • ループバックデバイスの必要がないことに注意
  • Fossil
    • 昨日何をやっていたか
  • Venti
    • 二度とファイルをなくすことはない
  • getpid、kill、ptraceはどこで実行されるの?
    • 単純:ファイルI/Oを/procファイルに換えるだけ

まとめ

  • OSUnixの元々の簡潔さを保つことができるのか?
    • 大抵のことはパスである。異なる資源に対する共通のアクセスモデル
  • ...さらに、現在のUnixの能力を付け加えてでも?
    • ネットワーキング、ネットワークファイルサービス、グラフィックス
  • Plan 9はその問いに「是」と答えている
  • Plan 9Unixよりもずっとよくやっていることを除けば

さらにまとめ

  • われわれは1978年にどこにいたか?
    • とてもよい場所だったが、道を誤り始めていた
  • 今どこにいるのか
    • 長い道の果て、それはおそらく終わりを迎えようとしている(がそうでないかもしれない)
  • どこに行けるのか?
    • 別の道を探そう
  • でも、それは簡単ではないだろう...