RUNES

新しいプラグインシステムの名称。
Role-based Unified Network Extension System
なんて。

読み方は
るーねす
（るーんず の方が良い？）

毎度のごとく語感優先。

プラグインシステムはそれ自体で未踏というわけでも無さそうなので、由来無しはちと良くない気がした。
その点VIVERは挑戦的な。

で、起動時に依存関係処理をするのはやめた！
でも適用順の順番制御は起動時にやるのだ。依存関係処理だけプラグイン管理ツールに頼る。

そういえば、プラグインをどこに配置するか（ディスクイメージの中か、ディスクに直接か、ハタマタ）という問題をまだ解決していなかった。

initrdにくっつけてしまうのが一番楽なんだけどな。でもそうするとまたブート時間が延びる…。メモリの無駄も増える。

ディスクに直接置くのは、ディスクからブートするマシンは良いのだけど、ネットワークブートするマシンはどうするか？

NBDをもう一本張って共有するのは微妙。

かといってftpとかtftpとかを使うと、ダウンロードしたファイルをメモリに置かないとけないので、メモリの無駄が多くなる。ランダムアクセスできなくて起動が遅くなるし。

NFSはportmapが要る。ぇー

む！v9fsという手が！

v9fs = Plan9 9P2000リソース共有プロトコルのLinuxへの移植 ですよ。

確かサーバー側は小さいユーザーランドなデーモン、クライアント側はカーネルさえあればマウントできたはず。（前に1度試した）
これはイケルか？

実はVIVER 0.2を作るとき、NBDではなくてv9fs上に置いたディスクイメージをループバックマウントしようかと考えていた。
NFSと比べて、Plan9的シンプル構造なので、共有しているファイルシステム上に置いたディスクイメージをループバックマウントしても、通信内容は実質的にNBDで共有しているのと変わらないらしい。

v9fsって、TCPソケットの代わりに標準入力と標準出力にP92000プロトコルを流してマウントできるとか、ブロックデバイスを共有できるとか、named pipeも共有できるとか、「Plan9的」なところが面白かったりする。
プラグインシステムとしても、結構使える機能になるかもしれない。

クライアント側はLinuxカーネルにマージさているので、使うのは簡単。
さして議論になることもなくさくっとマージされた所を見ると、コードの量も少ないっぽい。（同じ時期にFUSEが騒がれていたからという可能性も）
（P92000をWindowsに移植しても、FUSEっぽいモノになるかも）

問題は、サーバーが落ちたらどうすると。
せっかく分散ディスク共有でシングルポイント障害を無くしても、これじゃおいしくない。

ずっと共有していないといけないファイルのサイズは小さいから、cachefsでも使えばOK？
ディスクキャッシュ分で何とかなるだろとか？
そんなテキトーじゃダメすかね…

プラグインシステム側で、「起動時以降はリソースにアクセスできるとは保証されないので、ずっと必要になるファイルは適当な所にコピーしておくこと」とするのが良いか。運用でカバー。