hostfs は、 ホストPCのファイルシステムにアクセスする手段として使われています。 しかし、可能性としては、もっと大きなものがあります。 hostfs は、UML空間、ホストPCのカーネル空間からともに切り離され、 独立した存在として、ホストPCのユーザ空間で走っています。

最も簡単な拡張としては、hostfs をほかのマシンに置き、UMLと RPCで通信するようにすることです。これは、ほかのマシンのファイルを UMLからマウントできるようになります。ユーザ空間における nfs デーモンのような存在です。

もっと興味深い可能性としては、 hostfs を拡張し、 ファイルシステムによく似た見掛けだがファイルシステムでないものを ファイルシステムとして見せる、ユーザ空間におかれたソフトとすることです。 たとえば、ファイルシステムのように見せかけたら面白いだろうな、 と思われるデータベースがいろいろあります。

• SQL databases - それぞれの行はディレクトリ、それぞれの列は ファイル。列の中身はファイルの中。
• /etc/passwd and /etc/group - それぞれの行はディレクトリ。 行の中身は、それぞれのファイルとなって ディレクトリの中にある。 上のSQLの場合みたいにね。
• NISやBINDみたくのネットワークデータベースにも適応可能
  

ほかの可能性。 たとえば

• ネットワーク - ネットワークの設定情報。それぞれのパソコンについて ディレクトリがあり、その中に、そのパソコンの設定についての 情報がある。
• ユーザ情報

そして多分もっといろいろ。 ファイルかファイルシステムみたいに見えるものなら、 UMLにファイルシステムとしてマウントできるはず。

このために必要なことは、 arch/um/fs/hostfs/hostfs_user.c のリライトだ. これは、UMLから見えるファイルシステムの 元となっているオブジェクト （今ならホストPCのファイルシステム） に対する操作を定義している。 別の種類のオブジェクトに対しても 適切な操作を定義すれば、 このオブジェクトはUMLに対しファイルシステムとして マウントできる。

同じデータを複数の場所におき、それを ひとつの hostfs としてマウントすれば、ほかの可能性が広がる。 （訳注：ここ、すこし意味不明）

• あるデータを、ファイルシステムとして、データベースとして、 それぞれの側面からマウントして、hostfs より どちらの側面からもアクセスできるようにする。 こうすれば、普通のファイルアクセスとしての使い方もできるし、 DBアクセスとしての使い方もできる。（超意訳）。
• 複数の（仮想）マシンの同じディレクトリを、ある仮想マシンに まとめてマウントすれば、そこにあるソフトをインストールするだけで、 ほかのマシンからも見える。（かなり意訳）。

UMLにおけるSMPは、シングルCPUしかないマシン上に、マルチプロセッサを あたかももっているような仮想マシンを作る。 これを実現するのはそんなに難しくない。 別のことをやるために中座してるけど、２０００年のはじめあたりは コーディングしていたよ。

これを実現するために後やること：

• SMP config ( arch/um/config.in ) のコメントアウトをはずしてリコンパイル。
• といっても、コンパイルの際にはいろいろと問題があるかも。 まあ、昔のソースだからしょうがないね。
• UML arch code を リライト。 グローバルデータをロックしているところを探して （そんなにたいしたことじゃないぞ。ほとんどは Jeff Dike が修正済み）
• デバッグして、
• パッチ送ってね.

DSM てのは、分散共有メモリ（Distributed Shared Memory ） のことであり、 なんらかの特別なネットワークにより、マシンの一部のメモリが お互いに共有されているクラスタだ。

これには、UMLが使える。 UMLの物理メモリ（とされている存在）は、実際には ホストPCのOSが作った仮想メモリ空間だ。 だから、そこには物理メモリが張り付いているかもしれないし、 そうじゃないかもしれない。 単一のUMLのインスタンス（存在）を複数のマシンに分散させるには、 こうするんだ。 あるマシンに存在しているメモリのページは、 ほかのマシンからは剥ぎ取る。 剥ぎ取られたページへのアクセスが発生したら、 そのページフォールトを利用し、 新しい低レベルフォールトハンドラが どのマシンにそのページがあるかを探し、 それをとってくるのだ。

これは、UMLベースのシングルシステムイメージクラスタ（SSIクラスタ) を構成する。 でも、（もうわかってると思うけど）これじゃあ滅茶苦茶遅い。 だって、カーネルデータの参照なんて頻繁でしょ。 だから、ネットワーク越しにメモリページのデータのコピーが すさまじい勢いでおきる。

この問題の解決には二つのやり方がある。 ひとつは、 何もせず放って置いても、 LinuxにおけるNUMA関連の開発が すべてを癒してくれるのではないかな、ということ。 だいたい、UMLは、仮想的にNUMAを作れるから、NUMAのマシンを 持ってない人もNUMAの開発に参加できるようになるし、 それによってNUMAの開発が促進されるかもしれないし。 そうやって、NUMAの開発が進めば、すべてが解決する、かも。 （超意訳）。
訳注：
NUMA - Non Uniform Memory Access. マルチプロセッサシステムの 形態のひとつ。ソフトウェア的にはSMPと同じ感覚でいい （すべてのメモリが共有されている）が、ハード的には すくなくとも等しいアクセス速度を持つ存在としては共有されていない。 「共有されていない」のではなく、等しいアクセス速度としては 共有されていない、というところがポイント。
Jeff Dike がいってるのは、NUMA でもネットワーク分散でも、 自分のCPUが管理してないメモリのアクセスがひどく遅いということでは （といっても、その「遅さ」のレベルは違うが）共通じゃん、ってこと。

もうひとつは、共有されているメモリのデータのやり取りを RPCでやることだ。 NUMA関係のLinuxの開発によって、このやり取りの量は減るだろう。 そして、RPCでやり取りをすればやり取りは効率化するだろう。

いずれにせよ、最終的には、一台のマシンでも複数のマシンでも、 ひとつの大きなマシンとして認識できるようなる。

UMLは普通 ひとつのコマンドとして動くが、 それに限定される必要はなく、ほかの形態もありうる。 たとえば、ほかのアプリにリンクされるライブラリとか。 UMLをリンクしたアプリは、UMLの上で動いているのと ほとんど同じことができる。

• memory allocation - メモリ割り当て。 これらは、高速でかつ拡張性があるようにチューニングされている。 加えて、バディアルゴリズム（ようは、2の累乗単位で割り当てろってこと）で 分断化がおきにくいように割り当てることができる。
• memory management - メモリ管理。UML内部のスワップとキャッシュサイズの管理。 ちょっと改良すれば、ホストPCのLinuxに対し、UMLは、 アプリが本当にいるメモリ量をつげ、それにより、 より効率的なメモリ管理ができるようになるはずだ。
• virtual memory and multiple address spaces - 仮想記憶と多重アドレス空間。 これらは、libc がやってくれないことであって、 やりたいなら、カーネルを直接呼ばないとだめだ。 これは、アプリのスレッドを「jail」に閉じ込めるのに 使えるだろう。 信用できない動きをブロックできるのだ。 highmem がUMLでサポートされれば、 これらは4Gを超えるアドレス空間のアクセスに役立つはずだ。
• threads - スレッド。 これらは、（Linux のスケジューラそのままなので） オーバヘッドが少なく高速である。
• filesystems - ファイルシステムは、アプリケーションの内部データの 階層化記憶システムとして使える。 これらは、いってみれば内部ラムディスクとしてマウントでき、 外からは見えない。プロセスが落ちれば消えるけど。 消えたくないなら、ファイルに貼り付ければいい。
• the full network stack and network devices - これは、アプリ内ファイルシステム（前項）と組み合わせると 面白い。それらをNFSとかで外に出せるよ。

これらがどのように使えるかのサンプル。

• アパッチでの応用。 アパッチでUMLをライブラリとして使えば、 アパッチの設定を、内部ファイルシステムにおける。 で、それをネットワーク越しで外に出せる。 たくさんのアパッチサーバを持っているところだと、 それらの設定をひとつのサーバにまとめてマウントして、 集約管理すれば便利かも。
• もちろん、外に設定を出すだけではなく、 中央管理サーバから設定をすることにも使える。 バーチャルドメインの設定とかにいいかも。
• 外に出すのと、外から入れるのは 矛盾することじゃないから、 各アパッチサーバの設定を中央管理サーバから見つつ、 各アパッチサーバに中央管理サーバから設定することは可能だよね。
• これらのサーバは、UMLが作った「jail」のなかで動かせる。 また、jail の nice とかを設定しておけば、 CPU時間の公平な分配にもつながるかも。
• スクリプト言語をつける：
  スクリプト言語とのインターフェースにもいいかも。 自前のスクリプト言語を持たない、インタラクティブなアプリがあるとして、 そのUIを内部ファイルシステムにマップし、それを外に出せば、 ほかのスクリプト言語とのインターフェースになる。
• たとえば、外に出したファイルシステムを監視し、 そこにダイアログボックスを現すファイルが出現したら、 そこになにか書く、ってスクリプトを作る。 そうすれば、たとえば、デフォルト値を持ってないアプリがあるとして、 そこに、自分の好きなデフォルト値を入れることができる。 あと、同じような原理で、アプリ間のちょっとした 連携の実装にもなるかもしれない。 たとえば、GUIのメールソフトがあったとして、メールのTo:欄を あらわすファイルを内部ファイルシステムの中に作っていて、 それを外に出してくれてれば、DBとTo:欄の連携を図る スクリプトなんてのは簡単に作れるだろう。（超意訳）。

UMLをクラスタとして使う考えとライブラリとして使う考えを 融合させれば、 （たとえば、apache みたいに複数のプロセスを立ち上げるアプリで） 立ち上げたプロセスを複数のマシンにおくって、効率よく実行することが できる。 カーネルのデータ構造とアルゴリズムはもうほぼこれが可能な状態と なっている。

負荷が上がったら新しい仮想ノードとして新しい 本物のマシンを加え、負荷が下がったらそれを切り離す。 切り離されたサーバは、別のクラスタシステムが使うだろう。 つまり、サーバ群のなかで、複数のサービスが、 必要に応じてサーバを取り合うのだ（超意訳）。