[OSASK 4992] BOARD: Re: Re: OSASK へのコメントへの ...

このメールは、OSASK伝言板に書き込まれた内容です。
この書き込みに返事を書く場合は、下のURLから書き込みを行なって下さい
http://www.imasy.org/~mone/osask/index.cgi?REFER=3d849c39_d295

2002/09/15 23:42
匿名の臆病者

匿名の臆病者です。

> 僕が唯一疑問に思うのはここだけです。
> 僕にはこれらの点は利点だとは思えません。

> 名前をつけなければ区別して指定することは面倒になります。
> ディレクトリ構造も同じ事です。セキュリティーもつけられません。
> これがメリットなのでしょうか?

「できない」のではなく「しない」のです。
名前を区別したり、複雑なディレクトリ構造を用いたり、
セキュリティーをつけたりする「必要がない」のがメリットです。
そこで効率を稼げるわけです。

逆にいえば、

1.スワップファイルを通常のファイルと同じように
  名前をつけてユーザが区別できるようにすること
2.複雑なディレクトリ構造を用いてユーザが
  スワップファイルを通常のファイルと同じように管理できるようにすること
3.スワップファイルに通常のファイルと同じような
  セキュリティ機構を導入すること
4.スワップファイルを通常のファイルと同じように
  突然の電源断から守れること

に、どれだけメリットがあるのか、ということになります。

1.と2.についてもっと踏み込むと、
もちろんプロセスのヒープやスタックに名前をつけて区別できたりしたら便利
(例えばデバッグ時など)ですが、
それがファイルシステムで実装されている必要はありません。
現行の OS に見られるような procfs や、より洗練された Plan9 の
名前空間の手法のように、オブジェクトのレベルまで抽象化して
名前管理をしたほうが、効率のよい実装が可能です。

3.についてもっと踏み込むと、
オブジェクトのキャッシュを扱う部分でセキュリティ機構が
既に実装されているので (つまり、メモリ管理システムが
プロセスのヒープやスタックを他のプロセスから保護しているので)
さらにスワップファイルの保護を実装する必要はありません。


スワップファイルシステムが無いことの
利点は、カーネルの実装で楽ができる点だと思います。
通常のファイルシステムだけ実装すればよいのですから。
ただし、その楽さ加減は、上述の 1、2、3、4 のような効率の問題との間で
トレードオフの関係になるでしょう。


> 僕は別に新規性にはこだわっていませんが(むしろ前例があればうまくいくと
> いう証拠なのでありがたいくらいです)、スワップファイルシステムをなくして
> みたOSは無いようなので、やはり新規性にカウントすることにします。

今回のコメントの流れのように新規性を主張されれば全く問題はないと思います。
例えば、短くまとめてみると
...
従来の OS ではプロセスのメモリヒープやメモリスタックなどの
データバックエンド(つまりスワップ領域)として
特別なスワップファイルシステムを用いてきたが、
OSASK では全く通常のファイルシステムを用いる。
これによりスワップファイルシステムを実装しないですむので
カーネルの実装を簡略化することができる(はずである)。
...
そして、このアイデアがうまくいくかどうかは、
川合様の腕にかかっている、というわけです。


ML番号でジャンプ
ML単語検索