Infernoパート0：名前空間

FAQ： OS Infernoとは何ですか、なぜ必要なのですか？



私は約束しましたが、Infernoをインストールして実行する方法に関する投稿をまだ書いていません。 私はそれを一連の記事にまとめましたが、これは最初の入門編です。 名前空間について少しお話します。 これはOSの重要な部分であり、Plan 9およびInfernoが現在コンピューターで実行されているものと大きく異なるものの1つです。



インフェルノはほとんど知られていないので、私は彼女に伝道するつもりはありません。 Infernoの使用方法と、Infernoが機能する理由を説明するために、歴史と実践のギャップを狭める手助けをしたいと思います。



私は少し横に外れなければなりません。 名前空間の進化について、時系列順ではなく、機能の開発順で説明し、次にInfernoの機能の使用方法を示します。

内容

• ドス
• Unix、Linux
• プラン9、インフェルノ
• ...まあ？
• 最後に、入力できるもの
  
  
  • ルートはマウントする必要はありません
  • mount -o loopおよびFUSEは不要です
  • カーネルドライバーは不要
  • chrootは必要ありません
  • Simlinkは不要
  • ソフトウェアをインストールするために、$ PATH、$ LDPATHおよびルート権限は必要ありません
  • NFSは必要ありません
• 強力なプリミティブは、決して後悔しないことを意味します
• 未来のどこか
• 続く

ドス

DOSを覚えていますか？ A：とB :、ドライブがありました。 C :、ハードドライブなど。 これらの各ドライブにディレクトリ階層がありました。 （不必要な詳細は省略します。）鉄に結び付けられた、フラットで上位の1文字の名前空間と考えることができます。 1ドライブ-1文字。

Unix、Linux

しかし、Unixでは、トップレベルのディレクトリ「/」がありました。 ルートディスクがそこにマウントされ、他のすべてのディスクはルートディレクトリのサブディレクトリ、サブディレクトリのサブディレクトリにマウントされました-このディスクを表示しますか？ システムのセットアップに関与しているか、いずれかのパーティションの空き容量が不足していない限り、どのパーティションまたはディスクを知る必要はありません。 これは、OS全体に共通の階層的な名前空間と考えることができます。



これは、はるかに柔軟で強力なアプローチです。 プログラムとユーザーは、どのドライブの内容を知る必要はありません。



その後、新しいタイプのファイルシステムがUnixに登場しました：合成。 たとえば、/ proc。 Linuxには/ sysもあり、/ devが合成ファイルシステムを持つことも珍しくありません。 これらのファイルシステムのファイルが格納される物理ディスクはありませんが、それでも、プログラムはそれについて何も知る必要はありません。 ファイルは他のファイルと同様に名前空間で表示され、これらのファイルシステムでファイルを読み書きできるようにプログラムを変更する必要はありません。



ある意味では、それらの間にファイルシステムがあり、通常はディスクにファイルを保存しますが、ユーザーはおそらくこれを知ることも証明することもできません。 たとえば、NFSはファイルとディレクトリの階層を含むリモートサービスです。



次はFUSEで 、ユーザー空間にファイルシステムを提供します。 FUSEを使用してローカルOSカーネルと対話し、ドライバーの作成対象を実装すると、OSカーネルの実際のドライバーを作成することなく、任意の合成ファイルシステムのサービスを作成できます。 （私はBSDを急いでいます; DragonFlyはいくつかの興味深いアイデアを開発しましたが、Plan 9からは機能が少なかったようです。）



一方、名前空間はシステム全体に共通しているため、変更するにはrootになる必要があります。 ランダムなユーザーが/ sbinの上に何かをマウントし、さらにumountコマンドを捨てたとします。 カスタムマウントはマイナーな例外であり、ある意味では根本的に何も変更しない松葉杖です。FUSEファイルシステムは任意の_ your_ディレクトリにマウントできます。 （ところで、LinuxにはPlan 9とInfernoで使用されるプロトコルである9P2000のドライバーがあります。）



以前は、ファイルシステムは1か所にしかマウントできませんでした。 Linuxの「バインドマウント」はもう少し柔軟性を提供します。ファイルシステム（またはその一部）がネームスペースのどこかですでに利用可能な場合、 mount --bind



介して別の場所に接続できます。 これは比較的最近追加されたものであり、2.6.26カーネル以前では、同じファイルシステムを1つの場所で読み取り/書き込みモードでマウントし、同時に別の場所で読み取り専用モードでマウントすることはできませんでした。

プラン9、インフェルノ

Plan 9とInfernoは、歴史的なUnixセマンティクスのいくつかの大きなチャンクを取り出し、それらをウィンドウから除外し、主要なOSの仮定のいくつかを捨てました。 私は今インフェルノについて話していますが、これのほとんどすべてがプラン9にも当てはまります（そして最初に登場しました）。「インフェルノ」と言うとき、「とプラン9」に括弧で安全に追加できます。 これらの仮定は特定の順序で示されるものではなく、便宜上番号を付けただけです。



最初の仮定は、最も簡単に破り、おそらく振り返ってみると最も明白でしたが、名前空間のファイルとディレクトリはディスク上のオブジェクトを表しているということです。



2番目の仮定は、ファイルシステムとマウントポイントの間に1対1の関係があるということです。 つまり このファイルシステムは1か所でのみ接続され、この1つのファイルシステムのみがこの場所に接続されていること。 この仮定を取り除くとは、ファイルシステムとそれが接続されている場所が互いに独立しており、同じ場所に任意の数のファイルシステムを接続できることを意味します。



3番目の前提は、実行中のシステムと名前空間の間に1対1の関係があるということです。 名前空間の変更が名前空間とその子孫を変更したプロセスにのみ表示される場合、他のユーザーが行った名前空間の変更からユーザーを保護する必要はありません。 ユーザーがファイルシステムを読み取ってマウントする権利を持っているだけで十分です。



名前空間に関するこれらの仮定を捨てることにより、はるかに強力なシステムを得ることが可能になり、この違いは一見するとそれほどはっきりとは見えないかもしれませんが、実際にはDOSとUnix名前空間の違いと同じくらい大きいです。



これらの3つの前提は、Unixライクなオペレーティングシステムではさまざまな程度に違反し、成功の度合いにはさまざまな違反がありました。 最初の仮定は、Unixでは正常に破られました。 たとえば、ほとんどすべてのUnixに/ procがあります。 FUSEを使用すると、ユーザーはファイルシステムをマウントでき、他のユーザーからファイルシステムを隠すこともできます（もちろん理想的ではありません）。 バインドマウントにより、ネームスペースの一部が別の場所に表示されるようになり、2番目の仮定に違反しますが、ルートが必要になります。 ユニオンマウントは、Unixへの道も進んでいます。 しかし、最初の仮定を除いて、これらのソリューションはすべて完全ではありません。 Unixの荷物を運ばずに最初から始めたらどうなるでしょうか？



各プロセスの名前空間には独自の（正確には、どのプロセスも名前空間をフォークできますが、フォークする必要はありません）ので、誰でも問題なく、どこでも何でもマウントまたは接続（バインド）できますセキュリティ。 マウントポイントには任意の数のマウントされたシステムを含めることができ、すべてに同時にアクセスできるため、あるファイルシステムを別のファイルシステムにオーバーレイすることが可能になります。 適切なプロトコル（Infernoの場合は9P2000）を使用している間、どのファイルシステムも「本物」または「合成」であるため、何でもファイルシステムであり、ファイルを処理するプログラムはそれを使用できます。



ハッキングまたは不正なソリューションの多くは、不要になったため、突然消えます。 明らかに、sudoのように、rootに委任されたものの多くはもはや必要ありません。 chrootは不要になりました。 シンボリックリンクは必要ありません。 OSのカーネルに組み込まれた膨大な数のドライバーは必要ありません。 NSFおよび/ etc /のエクスポートは必要ありません（良い乗り心地）。 mount -o loop



不要です。 mount --bind



必要mount --bind



ません。 FUSEは必要ありません。 $ PATHでさえ不要になり、ソフトウェアをインストールするためにrootになる必要があります。

...まあ？

Inferno（およびPlan 9）のドキュメントで私を悩ませていることの1つは、科学記事、マニュアルページ、ソースコードがありますが、ハウツーの教科書やドキュメントはほとんどないことです。 たぶん、 HOWTOのコーヒーの作り方に付属しているLinuxに甘やかされています。 始めるのは簡単な作業ではありません。特に、システムについて十分な知識がなくて、システムを使って自分で勉強するのが難しい場合です。 試してみますが、なじみのないコマンドを実行するなじみのないシェルがあり、リファレンスとして書かれたマンページはあまり役に立ちません。



それで、「まあ？ 以前に魅力的な約束を聞いたことがあります。 これをどのように使用できますか？」そして、これをいくつかの具体的な例と組み合わせて、何が起こっているのかを説明します。

最後に、入力できるもの

不要になったこれらすべてのものを覚えていますか？ それらのそれぞれは、より良いものに置き換えられており、それらのいくつかは、それぞれより優れたいくつかのものに置き換えられています。 これらの例では認証を無視するつもりです（簡単にするため）が、Infernoで認証と暗号化の方法を選択できると言います。

ルートはマウントする必要はありません

とても簡単です：

 bind '#p' /n/prog
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これにより、/ n / progにprogファイルシステム（/ procに類似）がマウントされます。 ちなみに、Unixの場合と同様に、/ progファイルシステムを介してプロセスを実行することで通常行われるすべてを管理、デバッグ、および実行できます。 違いは、リモートマシンをローカルでマウント/プログレする場合、リモートプロセスでこれらのすべてを実行できることです。sshを使用せず、リモートマシンでデバッガを実行する必要もありません。 はい、 kill 15



ローカルで実行できます。これにより、リモートマシンでプロセス15が強制終了されます。

mount -o loopおよびFUSEは不要です

コンピューターに多数の.isoファイルがあります。 それらが/ n / cdsにあり、そのうちの1つを接続したいとします：

 ; 9660srv /n/cds/dfly-i386-3.0.2_REL.iso /n/dfly ; ls /n/dfly
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

現在、現在のプロセスとその子孫はこのCDの内容を見ることができます。 特別なものは必要ありません。 9660srv（4）は、一方でISO-9660ファイルシステムを読み取る方法を知っており、他方で9P2000プロトコルをサポートしています。



Infernoには、たとえばtarアーカイブを読み取り専用ファイルシステムとして扱うtarfs（4）もバンドルされています。

カーネルドライバーは不要

まあ、ほとんど。 ファイルシステムをエクスポートするだけではなく、最終的にioctl（）を忘れることができます。 カーネルによって提供されるドライバーは/ dev / driversファイルで確認できます。これはかなり短いリストで、一般的なUbuntuまたはArchマシンでのlsmod



の出力よりも短いものです。



ほとんどのオペレーティングシステムで新しいファイルシステムをサポートするカーネルドライバーが必要な場合、Infernoはmodprobe（つまりルート）を必要とせず、カーネルに触れて新しいファイルシステムを追加しません。 上記の例でカーネルがISO-9660を知る必要がなかったように、 ext2fsをダウンロードすることでext2（読み取り専用）サポートを取得できます。

chrootは必要ありません

プロセスはそれ自体の名前空間を作成できるため、信頼できないプロセスに表示するのに危険なものはすべて名前空間からアンマウントでき、 pctl（2）システムコールを使用してプロセスがドライバーをマウントしないようにすることができます。 すべてがアンマウントされるという極端な例（したがって、組み込みのシェル機能を使用する以外には何もできません）：

 ; load std ; pctl newns ; pctl nodevs ; unmount / ; ls / sh: ls: './ls' file does not exist
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、何か便利なものが必要な場合は、単にすべてをアンマウントするよりも少し慎重に行動する必要がありますが、アイデア自体は単純です。



必要に応じて、ルートディレクトリの上にあるメモリにファイルシステムをマウントして、一時的なサンドボックスを作成することもできます。

 ; mount -bc {memfs -s} / ; echo Mad with power! > /asdf
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、もちろん、/ asdfはどこにも表示されません。 （これは、新しいファイルの作成にのみ適用されることに注意してください。）

Simlinkは不要

bindは、いくつかのディレクトリを他のディレクトリの上に置く機能を提供することにより、この問題を解決します。 たとえば、私はtinytkアイコンがデフォルトアイコンよりも多く設定されているのが好きなので、ウィンドウマネージャを起動する前にデフォルトアイコンをオーバーライドします。

 ; bind -bc /icons/tinytk /icons/tk
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

あるファイルを別のファイルの上に置くこともできます：

 ; echo Hello > some-file ; bind some-file /NOTICE ; cat /NOTICE Hello
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Infernoではシンボリックリンクは不要であり、存在しないため、ファイルシステムの循環参照の問題はほとんどなくなります。

$ PATH、$ LDPATH、およびルート権限はソフトウェアのインストールに必要ありません

私は$ PATHをいじるのが嫌いです。 私の.bashrcの大きな部分は、誰が最初に行くかを理解することであり、冗長なパスや他のアーキテクチャのバイナリを指すパスを追加することではありません。 Plan 9 Portをインストールしていますが、たとえば、Plan 9 manバージョンがLinuxバージョンと競合することは望ましくありません。



Infernoでは、実行するものはすべて/ dis（Plan 9の/ bin）にあります。 別の場所からプログラムを実行する場合は、単に/ disの前後にプラグインします。

 ; bind -bc $home/dis /dis
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、何かをインストールしたいが、/ disに書き込めない場合は、好きな場所にインストールし、/ disの上にプラグインします。 sudoは必要ありません。 / libと/ moduleについても同じことが言えます。

NFSは必要ありません

認証（-Aフラグ）と暗号化を無視するので、重要ではないものをエクスポートします：再びmemfs（4） 。 最初の車：

 ; mount -c {memfs -s} /n/mem ; echo something > /n/mem/asdf ; listen -A 'tcp!*!1234' { export /n/mem & }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2台目の車：

 ; mount -A 'tcp!thefirstmachine!1234' /n/remotememfs ; cat /n/remotememfs/asdf something
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ほとんどのファイルサーバーコマンドは、マウントポイントに接続する代わりにstdin / stdoutを介して動作できるため、ファイルシステムをネットワーク上でアクセス可能にするためにローカルにマウントする必要さえありません。

 ; styxlisten -A 'tcp!*!1234' {memfs -s}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、2番目のマシンで：

 ; mount -Ac 'tcp!thefirstmachine!1234' /n/remotememfs
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

listen（1）およびdial（1）コマンドは、Infernoのネットワークインターフェイスである/ netファイルシステムと対話するための便利なラッパーです。 Unixソケットは、BSDソケットライブラリ（対応するシステムコール）によって処理され、使用がはるかに困難です。 listenとdialは、netcatの同等物と考えることができます。 styxlistenも同じで、バイトストリームの代わりに9P2000プロトコル（プラン9で受け入れられるまでStyxとも呼ばれる）のみを送信することを想定しています。

強力なプリミティブは、決して後悔しないことを意味します

これはすべて、Infernoシステムコールの単なるラッパーであるいくつかの短いコマンドで実現されます。 bind（1）、mount（1）、およびunmount（1）があります。 イントロスペクションが必要な場合は、 ns（1）が役立ちます。



すべてのOSオブジェクトをファイルシステムとして表現するということは、cat、sed、echoなどのプログラムを使用して、たとえばip（3）ファイルシステムを使用してネットワークにアクセスできることを意味します。 ftpfs（4）を使用すると、対話型クライアントなしでlsおよびcpを使用できるため、スクリプトの記述が簡単になります（FTPクライアントを介したリダイレクトの必要はありません）。 実際、スクリプトは通常、ディスク上の通常のファイルではなくFTPサーバーで動作することを知る必要はありません。 zipfsを使用すると、.zipファイルをマウントできます。 それらを組み合わせると、FTPサーバー上の.zip内にある.isoをマウントし、そこから個々のファイルをコピーできます。

未来のどこか

私たちはすでに興味深いポイントにいます。 人口のほとんどは少なくともラップトップとスマートフォンを所有しており、そのうちのほとんどは自宅のコンピューターも所有しており、職場のコンピューター、タブレットなどを所有しています。 Unixの全盛期には、1台のコンピューターと多くのユーザーがいました。 これは当たり前のように思えますが、一般的なケースでは、1人のユーザーが多数のコンピューターを使用し、その逆はできないという状況にすぐに近づいています。



これらすべてのリソース（特にディスクとCPU）の管理は、すでに大きな問題です。 ファイルの同期、連絡先の同期など 電話に何かを処理するのに十分なリソースがない場合は、通常のコンピューターに（物理的にまたはssh経由で）アクセスする必要があります。 スマートフォンで映画を見たい場合は、そこにコピーする必要があります。 携帯電話で記事を読んで、ラップトップで読み続けることにした場合はどうしますか？ 自分にメールまたはIMを送信しますか？ （これはDBUSよりも優れていますが、これは余談です。）



これが続くとは思わない。 一時的な解決策として、すべてのデータをGoogle、Facebook、または「クラウド」サービスに提供できますが、そのような解決策には多くの要望が残されます（そして、理由をリストすることは別の余談です）。



コンピューティングリソースを管理し、これらすべてのマシン（ローカルおよびリモート）を組み合わせるという問題に対するソフトウェアソリューションは避けられません。 少なくとも現時点では、これをすべて可能にするプラットフォームの役割の最良の候補として、Infernoを考えています。 このシステムが突然このシステムに恋をした理由を完全に説明していない場合は、少なくとも部分的にはそうしています。

続く

この説明は非常に表面的なものです。 「すべてがファイルシステム」は、Infernoが構築する優れたアイデアの1つにすぎません。