新しいVFSモデル
(3rd par.)
i.e. → すなわち、つまり

(4th par.)
A messaging interface is preferable for many reasons, not the least of which
being that it makes stacking actually work the way it should work, as
independant and opaque elements which stack together to form a whole. For
example, with the new API a capability layer could be slapped onto a
filesystem that otherwise doesn't implement one of its own, and the enduser
would not know the difference. Filesytems are almost universally
self-contained entities. A message-based API would allow these entities to run
in userspace for debugging or even in a deployment when one absolutely cannot
afford a crash. Why run msdosfs or cd9660 in the kernel and risk a crash when
it would operate just as well in userland?

メッセージングインタフェイスは多くの理由から好ましいものです。特に
独立的で不透明な要素が積み重なって全体を形成するという、スタッキングが
本来すべき動作を実現するという点によるところが少なくありません。たとえば
新しいAPIでは、ファイルシステムが実装していない機能に対して機能層をあてがう
ことができ、エンドユーザにはその違いが分かりません。ファイルシステムは
大部分が自己完結型(注: 相互依存する別の要素を持たないという意味ね)の要素です。
メッセージベースのAPIではこれらの要素をデバッグのためにユーザランドで動作
させることを可能にしますし、また絶対にクラッシュしてはいけないような場合
にも威力を発揮します。msdosfsやcd9660がユーザランドでも同じように動作する
ならわざわざカーネルの中で動かしてクラッシュする危険にさらす必要はない
でしょう? ...