[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[b-free: 1271] Re: Memory Protection
今頃の res...
Takanori Hayashi wrote:
> h1suzuki> ホンとは、いま、宿題をしなきゃいけないのですが、息抜きという感じで、res します。
> ^_^
>
> ほんとは仕事をしなきゃいけないのですが・・・(以下略) (^_^;)
ははは。僕の方は数学史の試験で痛い目を見ました。誰も責められないだけに痛
かった。;_;
林さんも、お気をつけて。(笑)
> Rードのスタートアドレスはともかく他は実質的には可変じゃないかなあ。
> B-Freeの実装を知らないんで何ともいえないけど。コード領域の管理をSMB
> と同様に実装すれば実質的にはsegmentationなんですよね。
そうですね。>SMB
実行時の処理というのは、どういう風になっているんでしょう。
Process Manger が、File Manager を使ったり、Memory Manager を使ったりす
るのでしょうか?
で、code 用の memory は Process Manager が管理しているんでしょうか?
それだったら、実装の面から見ても、code を SMB にするのは適当ですね。
> h1suzuki> > UNIXでもセグメントの概念は使われています。コードセグメント、データセグ
> h1suzuki> > メント、スタックセグメントという分類でですけど。それでコードセグメント
> h1suzuki> > はプロセス間で共有できるように書き込み禁止とかするわけです。最終的には
> h1suzuki> > セグメントをリニアアドレスに割り付けるわけですけど。
> h1suzuki>
> h1suzuki> この割付は、動的な物でしょうか?
>
> 詳細は知らない。少なくともデータセグメントはかなり自由になると思う
> けど。コードセグメントについても、共有ライブラリなんかでアドレスが
> 衝突しないためには適当なアドレスにロードしないといけないからOSでは
> 自由に変えられるようになってると思うけど。
ふーむ。
Linux ではその辺どうなっているんですか?>Night さん。(^_^;
> h1suzuki> というわけで今までの話。
> h1suzuki>
> h1suzuki> Segmentation:
> h1suzuki> 固定 address 空間より、大きさの面で融通が利く。(4Gbyte max on 386)
>
> これはAアプリケーションのメモリマップを予めコードに4MB、データに
> 1GBなどと設定するより、プログラムを読み込む際にプログラムサイズの
> コードセグメントを割り当てた方がサイズ面で自由度が高くなるという
> ことで良いかな。確かにその通りだけど実装コストとの兼合いもあるから
> 固定が悪いとは一概には言えないですね。
うーむ。やっぱり、cost ですね。
BTRON1は仮想記憶なしの segmentation ですが、何か参考になりますかね
ぇ。
286が基本だから、全然参考にならないかも、、、。
みんなの意見が聞きたいなぁ。> Seg. or Fixed Addr.
> h1suzuki> 386 の Segmentation は、重いらしい。^^;
>
> セグメントのロードに時間が掛かるそうなので。実際にどのくらい速いか
> 遅いかは細かく調べないと分からないけど、セグメントを使うことで実装
> の手間を掛ける価値があるほど高速化するとは期待できないでしょうね。
> # ハードウェアでやってもソフトウェアでやっても権限情報などをロード
> # してチェックしなければならないのは同じで、386のセグメントセレクタ
> # は286との互換性の兼合いで複雑なんで速度は期待できないでしょう。
> # ソフトウェアで扱い易いデータ構造を作って使う方が速そうです。
移植性、、、。と言う話もありますしね。
> h1suzuki> 多重仮想空間 with paging:
> h1suzuki> 移植性がよい。
> h1suzuki> Segmentation を実現するための下地になりえる。
>
> ...何とコメントするべきか
これは失礼しました。
Segmentation と一緒に比べるなら、flat modelと固定 address の組み合わせを
言うべきですね。
たはは。<笑ってごまかす気か、、、。
>
> --
> Takanori Hayashi
> takanori@ohsaki.meidensha.co.jp
-Aki.