[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 2chのread.cgiへ]
Update time : 05/09 11:12 / Filesize : 132 KB / Number-of Response : 547
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

dragonfly bsd どうよ



125 名前:名無しさん@お腹いっぱい。 mailto:sage あんまり自信はないけど [04/08/16 01:00]
新しい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がユーザランドでも同じように動作する
ならわざわざカーネルの中で動かしてクラッシュする危険にさらす必要はない
でしょう? ...






[ 続きを読む ] / [ 携帯版 ]

全部読む 前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<132KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef