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

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



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


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

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




Ryuichi Naitoh wrote:

> o 図と説明では、中心核を ring0、周辺核が ring1、外殻が ring2 となって
>   いますが、これは何か理由があるのでしょうか?

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

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



>   i386 の ring 機構を積極的に使う理由というのが思いつきません。
>   他の OS でも i386 の ring 機構を 2 つ以上使っている OS はあまりない
>   と思います(使っていたのは、OS/2 ぐらいだったと思います)。

それをいったら、micro-kernel な OS 自体、すごく、少ないのではないでしょうか?
(一枚岩的 OS には元々2つしか存在しないから、2つ以上使う意味はない)



> o 積極的に ring を使うということでしたら、i386 では ring 間の移動は、
>   trap 命令ではなく、gate 命令を使うのではないでしょうか?

これは、もっともな意見ですね。OS/2 でも、call gate を使っているようです。
その辺の詳細は、まだ、全然、考えていません。


> 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 を呼び出すのは、アプリケーション -> 周辺核(マネージャ) 間
>   ではないでしょうか?

まず、LOWLIB は kernel のための trap handler として動きますよね?
App の実行環境を整備するために、manager との連絡もやりますよね。

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

で、僕が思ったのは、LOWLIB をより高機能にして、manager 間のそういった通信を支
援していこうと言うことです。

たとえば、ある manager が他の manager と通信したいときはどうすればよいのでしょ
うか? 
たとえば、CD 挿入 event の例を挙げます。CD の挿入を device driver が検知したと
します。そして、device manager に連絡したとしましょう。device manager はたぶ
ん、何らかの方法で、file manager や実身仮身 manager にしらせます。実身仮身
manager は window manager に知らせないとだめですねぇ。仮身を window に登録しな
くてはいけませんから。また、仮身を描画しなければいけませんから display
primitive みたいな部分にも連絡が行きます。

まあ、連絡が行くって言っても、ただ呼び出して何かをやらせるだけかもしれませんけ
ど、、、。

で、そういった相互の連絡を LOWLIB を(形式的にだけでも)利用して、統一感を持た
せた方が、program の保守の面で良いのではないでしょうか?



たとえば、実身仮身 manager (みたいの)が window manager へ何か働きかけるとき
に、実身仮身 manager はどうやって、window manager の存在(所在)を知るかという
問題があります。

要は、dynamic link library (ここでは manager の事を喩えてそういっている)の呼
び出しの時の name binding の話で、(たぶん別々に load される)二つの manager
が互いを呼び出すときに、相手先の名前(みたいな物)から entry point をどう見つ
けるかという話です。

Entry point を完全に固定しても良いのですが (BTRON1 のように int vector を割り
当ててしまうとか)、それだと、柔軟性が無くなる気もします。
そこで、LOWLIB にその辺のお膳立てをする機能を付けたらいいのではないかというの
が、僕の案です。


方法は、未だ、どうしたら良いのか分かりませんが、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 への呼び出しを回避
してくれたりとかもありだと思います。

# NT ではなんか、そんなことをやっているような話が
# 昔の ML にありましたっけ?>回避

# 外殻内の manager 達が process なら process 間通信機能を
# 普通に利用しても良い気がしますが、それでは遅い気がする。






>   周辺核が LOWLIB を介して中心核の機能を使うのはあまり必然性がないと
>   思います。イメージとしては、LOWLIB は ITRON の周りではなく、アプリケー
>   ションを覆う感じの方が正しいと思います(つまり、アプリケーションか
>   らは、直接 ITRON システムコールは使えず、呼べるのは LOWLIB だけとい
>   うこと)。

えっと、図では、ITRON の周りと言うことになっていますが、正確には、 集中管理棟
みたいな感じで考えていました。manager 同士の通信の時に、LOWLIB を経由すると言
うことです。ITRON kernel の直接呼び出しは、 不可能ではないですが、でも、確か
に、勧められることでもないですよね。だから、一応、ITRON の周りを覆うように描い
たわけです。

LOWLIB に manager 同士の情報交換をするための郵便局みたいになってもらう感じで
す。


>  o 図では、ドライバが ring1 で動くようになっていますが、現状では  ring0
>   で動くようになっています。ring1 で動く必要性はあるのでしょうか?
>   また、デバイスマネージャのところにあるイベントキューとは何物でしょう?

えっと、まず、必要性ですが、device manager を ring1 においたため、それと密に交
信するだろうと思われる device driver 達は ring1 においてみました。前の、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

  -Aki.