[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[b-free: 2057] Re: Manifesto英語版少し修正。




隆一です。


From: Hideaki Suzuki <h1suzuki@bridgew.edu>
Subject: [b-free: 2055] Re: Manifesto英語版少し修正。
Date: Mon, 07 Sep 1998 05:07:07 -0400

> いろいろ、突っ込んでくれて助かります。
> なにせ、Night さんが作られた B-free の解説書 (ps file のやつ)は、「周辺核の探
> 索」ということで結構おおまかな構成しか書いていないので、いろいろ、この機会に確
> かめておきたい所とかあった物で、、、。

そうですね。
この前の B-Free ミーティングの議事録にも書いてありますが、周辺核につい
ては考え中です。

今のところ考えているのは、(POSIX マネージャと同じように)周辺核を複数の
プログラムに分けるのはやめてひとつにまとめる、あるいは周辺核を小さくす
るということです(つまり、周辺核の機能も外に追いだしてしまう)。



> まず第一に、たぶん、Night さんは、ring を二つしか使わない user mode/kernel
> mode だけでの実現を目指していると思うのですが、それは、僕が思うには、その二つ
> (一枚岩の kernel と user programs)しかないからな訳で、B-free の方は少なくと
> も中心核・周辺核・外殻、そして app があるわけですから、4っつに分けた方が良い
> のではないでしょうか?

うーむ、それは何故でしょうか?
単に層として 4 つあるからというのは理由として弱いのでは?

私としては、保護の観点からみても 2 つで十分だと思います。
4 つにしない理由は、単純で OS が複雑になってしまうからです。

# Multics のようにセグメントによる仮想記憶と組み合わせるならば ring 分
# けするのも意味があるかもしれませんが、ページングによる仮想記憶だと
# 単にカーネル/ユーザモードだけで十分だと思います。



> 分けることの利点は、なんと言っても、app が周辺核や外殻に影響しにくい点だと思い
> ます。不利な点は、ring 間遷移での overhead ですが、どのくらいの cost がかかる
> ものなのでしょう?

えーと、アプリケーションのふるまいが周辺核や外殻に影響するという話なら
ば、周辺核と外殻がユーザモード(ring3)で走っていても同じ効果があるので
はないでしょうか?

周辺核や外殻が別の ring で動く必然性はないように思います。

ring 間遷移でのオーバーヘッドですが、gate 命令はそれなりにかかると
思いました(trap の 10 倍程度)。でも、最近の Intel CPU では改良されてい
るかもしれません。



> Ryuichi Naitoh wrote:
> 
> > o 図と説明では、中心核を ring0、周辺核が ring1、外殻が ring2 となって
> >   いますが、これは何か理由があるのでしょうか?
> 
> 上述の通りです。Kernel のみ保護されるより、manager 達も app から保護した方がい
> いのではないでしょうか?ならば、rign1 で周辺核と外殻を一緒にしても良いのです
> が、外殻の manager は process で動かす方が良いのではないかという気がしますの
> で、ring で切ってしまいました。これは、たんに、「けじめ」をつけるという感覚上
> の話で、ring1 より内側で走っているのが ITRON task で、それより外が process と
> いう事です。特に論理的な意味はありません。

うーむ、アプリケーションから保護するならば、別に ring3 で動いてもいい
のでは? 同じ ring レベルで動くと保護できないという話だと、アプリケー
ション同士はどうなの? という話になってしまいます。

ページングによる仮想記憶をサポートしている OS ならば、ring レベルは
2 つで十分だと思います。


> # ring が二つしか使えない CPU はあるかもしれないが、ring を
> # 三つしか使えない CPU なんてあるのか?
> # ってことで、4っつ使っちゃいました。(笑)

さて、merced ではどうだったかな…… :-)



> >   i386 の ring 機構を積極的に使う理由というのが思いつきません。
> >   他の OS でも i386 の ring 機構を 2 つ以上使っている OS はあまりない
> >   と思います(使っていたのは、OS/2 ぐらいだったと思います)。
> 
> それをいったら、micro-kernel な OS 自体、すごく、少ないのではないでしょうか?
> (一枚岩的 OS には元々2つしか存在しないから、2つ以上使う意味はない)

もともとマイクロカーネルの考えは、OS の機能のうち最小限の部分だけをカー
ネルモードで動かして、追い出した部分はユーザモードで動かすということで
しょう。OS の機能をユーザモードで動かすということだと、マイクロカーネ
ル OS で ring を多数使う意味はあまりありません。

また、マイクロカーネルだと、CPU に依存する部分を少なくすることによって
移植性をよくするということも考えていることが多いです。そうなると、
ring による保護は intel CPU に依存するものですから、使わない方がいいと
いうことになります。

でも、マイクロカーネルの OS って少ないですか? 最近の汎用の OS ってほ
とんどマイクロカーネルのような気が……。
(BeOS、Windows/NT、Mac OS X、Hurd ……)


> > o メモリマネージャとプロセスマネージャは、一部 ring 0 となっていますが、
> >   これは、中心核の中にメモリマネージャとプロセスマネージャの機能が一部
> >   入っているということでしょうか?
> 
> えっと、たしか、memory manager は一部 kernel mode で動く module があったと思う
> のですが、あの図では kernel mode は ring 0 になってますので、そういった意味で
> す。
> 
> 例の有名な図(全体構成):
>   http://www.sccs.chukyo-u.ac.jp/B-Free/bc/2/index.html
> 
> のうえで、kernel mode/user mode を仕切る line は、ring 0 の円だと考えてくださ
> い。

? この図にはプロセスマネージャはないですが。



> > o 「LOWLIB は ring 0 で動くため、ITRON3 の機能が使用でき、すべての
> >   manager 達の相互協調動作を達成するよう働きます。」とありますが、
> >   周辺核は、直接 ITRON を呼び出すのはいけないんでしょうか?
> >   私が今作っている POSIX マネージャは、そうやっているんですが……。
> 
> そのようですね。>呼び出す
> ITRON からの拡張機能とか。
> でも、本来は禁止して LOWLIB を利用した方が、安全なんですよね?
> 
> だから、本当に性能にひびく部分に最小限に使う方が良いのではないでしょ
> うか。

うーむ、周辺核が LOWLIB を呼び出す時に使うシステムコールは何を想定され
てます?  ITRON のシステムコールだとすると、LOWLIB を介する意味はほと
んどないです。

LOWLIB は、もともと ITRON のシステムコールで指定する資源が、保護されて
いないところから必要になったものです。アプリケーションから ITRON のシ
ステムコールを呼び出すことができてしまうと、他のアプリケーションのもつ 
ITRON の資源が操作できてしまいます。これを防ぐために、アプリケーション
からは直接 ITRON のシステムコールを呼び出すことができないようにしたの
が LOWLIB です。

で、LOWLIB は環境毎に複数あって、BTRON 環境用の LOWLIB、POSIX 環境用の 
LOWLIB というように分かれています。各 LOWLIB は、それぞれの環境のシス
テムコール(trap) を受けもち、必要に応じて ITRON システムコールを実行し、
周辺核を呼び出します。



> >   LOWLIB を呼び出すのは、アプリケーション -> 周辺核(マネージャ) 間
> >   ではないでしょうか?
> 
> まず、LOWLIB は kernel のための trap handler として動きますよね?
> App の実行環境を整備するために、manager との連絡もやりますよね。

はい。


> これは、たぶん、外殻の実身仮身 manager に当たるような部分が memory manager や
> process manager を呼び出し、それら二つが kernel の機能を利用して memory の確保
> などをするのですよね?

そうなんですか?
アプリケーションの初期化処理に「外殻の実身仮身 manager」が関与するとい
う意味がわかりません。

たとえば、あるプログラムがプロセスを起動するときは、次のようになると
思います。

1) プロセスマネージャに対してプロセスを起動するよう(LOWLIB を介して)依
   頼する。

2) プロセスマネージャが、新しいプロセスのためのタスクを生成。
   タスクの起動ルーチンとして、LOWLIB の関数(プロセスの初期化動作をす
   る)を指定する。

3) 生成したタスクにユーザプログラムを実行するための仮想空間を生成。
   実メモリとマッピングする。

4) ファイルからユーザプログラムを読み出し、生成した仮想空間へロードす
   る。

5) タスクを起動する。

6) LOWLIB のプロセス初期化関数が各マネージャを呼び出して、プロセスのた
   めの資源を確保する。

7) プログラムのエントリアドレスへジャンプ(カーネルモードからユーザモー
   ドへ遷移)する。

「外殻の実身仮身 manager」が関与するのは、プロセスが完全に起動した後では
ないでしょうか?



> で、僕が思ったのは、LOWLIB をより高機能にして、manager 間のそういった通信を支
> 援していこうと言うことです。
> 
> たとえば、ある manager が他の manager と通信したいときはどうすればよいのでしょ
> うか? 
> たとえば、CD 挿入 event の例を挙げます。CD の挿入を device driver が検知したと
> します。そして、device manager に連絡したとしましょう。device manager はたぶ
> ん、何らかの方法で、file manager や実身仮身 manager にしらせます。実身仮身
> manager は window manager に知らせないとだめですねぇ。仮身を window に登録しな
> くてはいけませんから。また、仮身を描画しなければいけませんから display
> primitive みたいな部分にも連絡が行きます。
>
> まあ、連絡が行くって言っても、ただ呼び出して何かをやらせるだけかもしれませんけ
> ど、、、。
> 
> で、そういった相互の連絡を LOWLIB を(形式的にだけでも)利用して、統一感を持た
> せた方が、program の保守の面で良いのではないでしょうか?
> 

うーむ、これは LOWLIB のような、独自のコンテキストをもたない(実は、ユー
ザプログラムにくっついているので、コンテキストはあるのだけれど) モノよ
り、別にマネージャを作った方がいいのではないでしょうか?


> たとえば、実身仮身 manager (みたいの)が window manager へ何か働きかけるとき
> に、実身仮身 manager はどうやって、window manager の存在(所在)を知るかという
> 問題があります。
> 
> 要は、dynamic link library (ここでは manager の事を喩えてそういっている)の呼
> び出しの時の name binding の話で、(たぶん別々に load される)二つの manager
> が互いを呼び出すときに、相手先の名前(みたいな物)から entry point をどう見つ
> けるかという話です。
> 
> Entry point を完全に固定しても良いのですが (BTRON1 のように int vector を割り
> 当ててしまうとか)、それだと、柔軟性が無くなる気もします。
> そこで、LOWLIB にその辺のお膳立てをする機能を付けたらいいのではないかというの
> が、僕の案です。

これって、メッセージベースだとダメなんでしょうか?
つまり、マネージャは、ITRON のシステムコールでメッセージバッファを作成
し、マネージャへはそのメッセージバッファを介して通信するわけです。

外殻だと BTRON レベルでのメッセージ機能を使った方がいいかもしれません。

直接(アプリケーションが)エントリポイントを呼び出すようにしてしまうと、
柔軟性がなくなってしまいますし、タスクやプロセスに対してそういうことは
できませんよね?



> 方法は、未だ、どうしたら良いのか分かりませんが、LOWLIB を "manager manager"
> (manager 達を manage:管理する物)みたいにできないでしょうか?
> 
> 
> たとえば、今考えられるのは、 LOWLIB 内に manager ID みたいな物を登録する table
> を作っておいて、manager が load された段階で manager は ID をもらえる。ITRON
> task ID か、process manager による process ID かもしれません。で、LOWLIB は同
> 時に、manager の名前から manager ID を検索する機能とかをもっている。で、
> manager A が manager B の機能を使うときに、manager ID と機能番号みたいな物と、
> 必要な情報を LOWLIB に渡すと、LOWLIB が process か task かなどを適切に判断し
> て、ITRON の task 間通信を使うなりなんなりして、通信を実現するわけです。LOWLIB
> の trap handler と似てますけどね。でも、LOWLIB を呼ぶ関数(LOWLIB のためにお膳
> 立てする部分)が、ある程度、いろいろ判断して、実際の LOWLIB への呼び出しを回避
> してくれたりとかもありだと思います。

いやまぁ、単純ながらすでにこういうものはあるんですが……。
ポートマネージャと呼んでいるんですが、名前とポート(メッセージバッファ
の ID)を登録/検索する機能があります。

# ソースは、/home/night/factory/btron-pc/kernel/BTRON/servers
# にあります。

ポートマネージャ自体の呼び出しは、ITRON のメッセージバッファを使ってい
ます(このメッセージバッファの ID だけは固定)。

すでに、POSIX マネージャやデバイスドライバはこのポートマネージャを
使って、自分の通信用のポートを登録しています。


> >  o 図では、ドライバが ring1 で動くようになっていますが、現状では  ring0
> >   で動くようになっています。ring1 で動く必要性はあるのでしょうか?
> >   また、デバイスマネージャのところにあるイベントキューとは何物でしょう?
> 
> えっと、まず、必要性ですが、device manager を ring1 においたため、それと密に交
> 信するだろうと思われる device driver 達は ring1 においてみました。

同じ ring では、交信が速くなるということでしょうか?
ITRON を介すと思うので速度的に有利だとはちょっと考えにくいんですが。


>                                                                   前の、b-free
> 2045:「外殻の探索1」を呼んでもらえば分かるように、僕は、BTRON1 OS 核の「デバ
> イス管理機能」相当のことは、device manager がやるべきだと思います。で、この機
> 能では event queue を実現しなくてはいけないわけで、そういう意味で、device
> manger に event queue を持たせています。
> たとえば、keyboard 用の device driver は直接、device manager に状況変化を報告
> し、event queue に key event を格納します。
> 
> 尚、「核イベント」 と呼ばれるものは、のちに、window manager から device
> manager への access によって読みとられ、window event として再構成されることに
> なります。

意味は了解しました。
ただ、このメイルの最初に書いたように、周辺核の分割については、
多分、変わってくると思います。


p----------------------------------------------------------------------q
| FROM R.Night                                                         |
| E-mail:                                                              |
|         rnaitoh@st.rim.or.jp                                         |
| Key fingerprint = 89 EB 77 95 40 C0 3C CC  37 A1 A7 FA 1C 66 FF D0   |
b----------------------------------------------------------------------d