[kernel-ml 17] Re: [b-free: 308] Re^3: About device driver manager

Naitoh Ryuichi ((no email))
Fri, 2 Jun 1995 00:26:01 +0900

隆一@B-Free です。
B-Free メイリングリストの皆さん、こんにちは。

例によって、カーネルメイリングリストにも振っておきます :-)。

>> On Thu, 01 Jun 1995 23:32:00 +0900, 真鍋 裕一 <NBG02534@niftyserve.or.jp> said:

>> うーん、こういうふうに実装してしまうと、デメリットの方が大きい
>> と考えてしまうのはおかしいでしょうか?
>  メリット/デメリットのどちらが多いかは、私には判断しかねます。出来るだけ制
> 約が無いほうが望ましいのですが、制約によって実装が簡単になると言うのであれば
> 、あとはトレードオフで決める事になると思います。
>  実際問題として、1プロセス当たりでサブタスクが幾つまで使用できれば適当なの
> かが判りません。おおよその値が決められるものでしたら、それを制限とすれば良い
> と思います。しかし、用途によって望ましいサブタスクの数に幅があるばあい、3B
> の様にサブタスクを7として決め打ちするのは、デメリットの方が大きいと思います
> 。

なるほど、そうですね。
私も、アプリケーションに、不要な制限を加えるのはやめた方がいいと思いま
す。

>  この問題は、プロセスのスタックエリアの大きさとも関連するかと思います。コー
> ド領域/データ領域はサブタスク間で共有しますが、スタックはサブタスク毎に割り
> 当てる必要があります。3Bの場合は、サブタスク一つ当たりのスタックサイズを最
> 大で512Kバイトに制限し、4Mバイトのスタック領域を8等分して使用するとの
> 事です。

そういえば、昔 Mach もこういう実装をしていると聞いて、あるタスクがスタッ
クをどんどん伸ばしていって、他のタスクのスタックを食いつぶしていくのを
どうやって防ぐのかについて疑問を抱いたことがありました。

# 結局、どうなっているのかわかりませんでしたが。。。

3B では、スタックの侵害をどうやって防いでいるのでしょう?
ひょっとして、その辺は何も考えていないとか? あるいは、512K バイトの領
域ごとにマッピングしていない仮想ページを 1 ページ置いておいて、侵害を
防いでいるのかもしれませんね。

-- 
内藤隆一 (ggc00661@niftyserve.or.jp/night@bfree.rim.or.jp)