特にLinuxの場合、実験的なものは「誰かがここにダンプしたコードで、当時は許容できるように見えたが、積極的に保守されていない可能性がある」ことを意味する場合があることに注意することが重要です。
私はファイルシステムをユーザースペースに保持することの大ファンですが、私がマイクロカーネルの大ファンであることも示す必要があります。次の理由から、ファイルシステムをユーザースペースに保持することが実用的で望ましいと思います。
ユーザースペースファイルシステムの保守が容易
非常に短時間でかなりの牽引力を獲得したPHDプロジェクトであるext3cowファイルシステムを見てみましょう。その作者は卒業してからキャリアに移り、ファイルシステムに取り組む時間はほとんどありませんでした。Linuxはツリーから外れているため、バージョン間で内部が変化し続けるため、最新のカーネルでLinuxを使用したい人は、多くの人が持っていない深い知識を持っている必要があります。
FUSE APIを使用した場合、保守がはるかに簡単になり、ext3をコピーオンライトファイルシステムに変換する実際の作業がより多くの人に公開されます。これは、誰もそれに触れるのに十分な勇気(または十分な退屈)がないためにカビを集めているカーネル内コードにも関連しています。
ユーザースペースファイルシステムのデバッグが容易
ユーザースペースには、Valgrind(およびmassifのようなその仲間)のような素晴らしいツールがあります。これらは非常に貴重なツールであり、使いやすいものです。カーネルのデバッグに関連する学習曲線は、多くの人がただ飛び込んでコーディングするには大きすぎることがよくあります。この回答に記載されているように、私はFUSEとマイクロカーネルアーキテクチャを明確に分離していることに注意してください。一部のマイクロカーネルベースのシステムは、主に実行中のサービス(vfs、ブロックデバイス、ファイルシステム、ipc)間の通信の競合が原因で、デバッグが非常に困難です。どちらの場合も、コードがカーネルの外にあるため、コードのデバッグが容易になります。ただし、コードがカーネルの外にあると、奇妙な複雑さが生じません。
いずれにせよ、私はGDBとValgrindをprintk()
いつでも騒々しいデバッグに引き継ぐか、Linuxに存在するかなり不可解なカーネルデバッグフックを理解しようとします。また、選択したデバッグ(またはガベージコレクション)のmalloc()
実装を使用する機能もお楽しみいただけます。FUSEで動作する場合は、選択したCライブラリにも同じことが言えます。私はLinuxのカーネルライブラリをダウンさせていませんが、私の生き物の快適さは好きです。
ユーザースペースファイルシステムは使いやすい
恵まれないユーザーにとって、使用したいファイルシステムをマウントして維持できるという大きなメリットがありますが、それは実際にはエンドゲームです。ファイルシステムがカーネルから外れている場合は、カーネルとは無関係にファイルシステムを進めることができます。つまり、ユーザーはリリースサイクルに合わせてアップグレードできます。Linuxが次のリリース候補に進むのにかかる時間で、6つのマイルストーンリリースを達成できると考えられます。これにより、ディストリビューションやOEMベンダーは、FSを実際に使用して、カーネルモジュールの場合よりも速く必要なテストを行うことができます。
Norman Ramseyは、マイクロカーネルアーキテクチャのサービスとしてのファイルシステムに関連する信頼性要因についてすでに説明しました。ただし、信頼性とは、バグやその他の問題を隠す(または延期する)傾向のある生まれ変わりサービスを必要としないことを意味します。ルートマウントに失敗してもカーネルアボートがスローされないという点には同意しますが、これはモノリシックFUSE対応カーネルでも可能です。
要約すると、ファイルシステムの作成は、カーネル空間での実行に対処しなくても十分に困難です。カーネルモジュールとして作成するよりも、FUSE APIを使用するか、マイクロカーネルベースのOSでのIPC/VFSサービスの実装を検討したいと思います。