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

[b-free: 2045] 外殻の探索1



以下の mail は、kernel ML に出したところ、SMTP delivery error で
返ってきたので、general ML に再送します。
しかし、tron-net が安定するのは、いつのことでしょうね。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−




えっと、この ML では、7月からの久しぶりの書き込みですね。:-)

題名にあるとおり、外殻仕様策定の一環として、外殻を探索してみましょう。

#さっき、かなり書いたのに N.Messanger が Int 13 くらった、、、。
#結構、精神的に辛いですね、、、ホント、、、。
#B-free は、ぜったい、fault tolerant な OS にしましょう!!!
#(まあ、こまめに save しなかった自分にも非はあるが、、、)




外殻を探索する前に、まず、中心核と周辺核に何があるのでしょうか?
また、BTRON1 仕様との mapping は、どうしたらいいのでしょう?


中心核:
  ITRON 3.0 micro kernel
  task 関連の処理

[LOWLIB: trap handler 及び全 manager の協調運用]

周辺核:
  Process manager
  Memory manager
  File manager
  Device manager


 ここで、device manager は、device drivers の system への登録・削除を管

理します。また、LOWLIB 経由で他の manager 達(app であることも可能)か
ら、特定の driver の所在(存在)を確認されたときの locator としても機能
するとします。たとえば、 file manager に特定の block device があるかどう

か LOWLIB 経由で device manager に問い合わせがあるとします。

 「こういう device はあるのか?」

すると、device manager は、自分に登録されている drivers のなかから適当な

driver を探し、もしかしたら、そんな device は無いと言うかもしれません
し、さもなくば、

 「Device access key(or port) は、これです。こういう操作が可能です。」

といった、情報を返す。 以後は、file manager は、この access key を使っ
て、(たぶん依然 LOWLIB 経由であるとしても)所定の device driver を直接
たたけるようになります。この access key を介して処理することで、一つには

LOWLIB の作り方によっては driver を直接叩けることによる処理の高速化と、
また、device manager に「どの app に key を配ったか」の記録を残すことが
出来ます。記録を残せば、device に何かしらの変化が起きて事象通知が必要に
なった場合、key を渡した process に device manager が通知すればよいと言
うことになります。 流れとしては、device manager → LOWLIB → file
manager とかいった具合です。

# 事象としては、device のmount/unmount など。

 File manager は、device driver が low level の操作をするのを受けて、も

う少し、高い次元の処理をします。具体的には、file system の構成と言うこと

になるでしょう。path から、file の保存されている場所を割り出して情報を入

出力したり、cache や buffering の整合性をとったり、lock をかけたり、
access check などが、主な仕事です。おおむねは、BTRON1 OS 核の file 管理
機能に相当する機能を提供する物だと思います。

  Memory manager は、仮想記憶と process manager のための memory 管理を提

供します。BTRON1 での LMB や SMB の管理などもここで行います。Process の
address space もここで、管轄するのかもしれません。

 Process manager は、process に属する context の管理・処理をします。
scheduling とかも、ここでやると考えて良いのでしょうかね。これより高位の
service は、process として存在することが出来るようになります。

 Memory manager と process manager が LOWLIB の調停のもと共同作業するこ

とで、BTRON1 OS 核の「プロセス管理機能」及び「メモリ管理機能」を果たしま

す。また、file manager は、「ファイル管理機能」相当の処理を提供し、
device manager は process manager と共同で「デバイス管理機能」相当の処理

を実現します。
 「システム管理機能」に関しては、B-free では、構造の違いから不要である
と考え、E_NOSPT を返す dummy を library として(もしくは、LOWLIB で)実
装する物とします。


 BTRON1 OS 核の中では、後のこるは、「イベント管理機能」「時間管理機能」

が存在します。

 時間管理機能は、ITRON の機能を直接 LOWLIB が使えば可能なはずです。


 問題は「イベント管理機能」を、どの構成要素で実現するかです。Event 自体

は、 device drivers からの通知が基本ですが、BTRON1 API の関係で、それを
統合する必要があります。また、event は、app からは直接操作されることはま

れで、window manager に当たる処理を経由して、app に分配されることになり
ます。そこで、event の管理(具体的には event queue の管理)は、device
manager がやると言うのが一番良さそうです。 各 driver は事象を device
manager の event queue に送るというのはどうでしょうか? driver からは、
よって、二つの事象通知の方法が与えられたことになります。一つは、event
queue への送付、もう一つは、device access key をもっている manager への
配信です。






この周辺核までで、BTRON1 のなかの OS 核の機能は大体可能だという感じにな
りましたが、次は、外殻の話になります。
外殻は、どういった風に構成したらいいでしょうか?


- Aki.

ps.
しかし、tron-net またおちてます?
B-free WWW に接続できなかったけど、、、、。
(中京大学の方に接続して用を足しましたけど)