[kernel-ml 3] About device driver manager.

Naitoh Ryuichi ((no email))
Sun, 28 May 1995 03:26:48 +0900

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

青木さんのメイルに対するコメントです。
b-free@iijnet.or.jp と kernel-ml@bfree.rim.or.jp の両方に送っておきま
す。

>> On Sat, 13 May 1995 09:33:00 +0900, 青木 義彦 <PBC03033@niftyserve.or.jp> said:

>  先月から休日無しモードに突入しており、出勤しなくてはなりません。
>  申し訳ありませんが、欠席いたします。

>  予定していた要員がトラブルではまってしまっていて、二人分の作業を
>  押しつけられているんです。(;_;)

大変ですね。仕事にめげずにがんばってくださいね ^^)。

>  ところで、質問なのですが、

> ・BTRONのプロセスが複数のサブプロセス(スレッド?)から構成されて
>  いるとき、各サブプロセスは同時にBTRONシステムコールを発行できる
>  のでしょうか?(ようするに、1つのサブプロセスがシステムコールを発行
>  して待ち状態になったときに、別のサブプロセスが実行できるかどうかとい
>  うことです)

これは、(BTRON)プロセス内で複数のタスクが動けるかという問題になると思
います。プロセスの中で複数のタスクが動くようになっている OS で、システ
ムコールも同時に発行できないというのは考え難いです。ぜひシステムコール
はタスク毎に別々に発行できるべきでしょう。

今のところ私のイメージでは、BTRON でいう処理単位をプロセスと呼び、
ITRON でいう処理単位をタスクと考えています。このイメージでは、青木さん
の質問にあるサブプロセスというのは、ひとつのプロセスの中で動くタスクと
いうことになります。
そこで、複数のタスクをプロセスの中で動かすためには、何をすればいいかを
考えてみました。

1) ITRON ........... もともとプロセスは関知していないので、変更は必要
ない。

2) LOWLIB .......... 複数のタスクが同時に LOWLIB を呼び出すことになる
ので、大域変数などを同時にアクセスできないように
排他する必要がある。また、プロセスの終了時に複数
のタスクを終了させるなどの処理が必要。
また、複数のタスクが同時にシステムコールを実行す
るためには、タスクごとにシステムコールの返答メッ
セージ用の ID をもつ必要がある。

3) マネージャ ...... システムコールは、メッセージとして送られてくるの
で、排他処理の必要はない。ただし、プロセスマネー
ジャについては、プロセス毎に複数のタスクを管理す
る必要がある。

というように、ひとつのプロセスで複数のタスクを動けるようにするには、
LOWLIB が一番考えなければいけないところだと思います。

> ・デバイスドライバマネージャは、アプリケーション(BTRONプロセス)
>  と、他の周辺核(ITRONタスク)の双方をサービスの対象にすることに
>  なっています。
>  一方デバイスドライバマネージャが管理する「デバイスディスクリプタ」は
>  BTRONプロセス単位に割り当てられることになっています。
>  したがって、デバイスドライバマネージャを利用する周辺核は、(疑似的に
>  でも)BTRONプロセスのプロセスIDを持つ必要が有ります。
>  「プロセスIDのXXは特殊な値で、周辺核を示す」というのでは全ての周
>  辺核でデバイスディスクリプタを共有できてしまうので、各周辺核ごとに別
>  々のIDを割り当てるのが望ましいでしょう。
>  このような実装は可能でしょうか?

えーと、実装として考えるとデバイスディスクプリタは、LOWLIB の中のオー
プン中のデバイスを管理する配列のインデックスを指すようにすればいいと思
いますが (UN*X みたいに)。
この場合、デバイスマネージャは、ユーザプロセスの情報は関知せず、単にデ
バイスとメッセージバッファを組にして管理するだけです。

このようにすると、デバイスをオープンするとき呼び出される LOWLIB 関数は
次のようになります(ここではとりあえず low_opn_dev() という名前にしてお
きます)。

/* LOWLIB の中の opn_dev システムコールの実行関数
*/
low_opn_dev (TPTR dev, UWORD o_mode, WPTR error)
{
ID dev_port; /* デバイスマネージャと通信するためのメッセージバッファ */
W index; /* デバイスディスクプリタ(システムコールの返り値 */

/* デバイスマネージャにデバイスをオープンする要求を出す。
*/
dev_port = opn_dev (dev, o_mode, error);
if (error != E_OK)
{
/* エラー処理 */
}

/* LOWLIB の中で管理しているデバイスディスクプリタテーブルの中から空
* いているエントリを取得する。
* このとき、デバイスディスクプリタテーブルの中にデバイスドライバと
* 通信するためのメッセージバッファの情報を入れる。
*/
index = alloc_devtable (dev_port);
if (/* デバイスディスクプリタテーブルに空きがない */)
{
/* エラー処理 */
}

/* ユーザプログラムにデバイスディスクプリタを返す */
return (index);
}

このようにした場合、周辺核レベルだとメッセージ ID を指定してデバイスド
ライバマネージャに要求を送るだけなので、プロセスのことは気にしなくても
よいことになります。

ただし、デバイスマネージャがアクセス権のチェックを行うためにプロセス
ID をチェックすることを考えているならば、この方法はそのままでは使えま
せん。
ただし、デバイスドライバマネージャがチェックするプロセス ID というのは
結局のところ送信元がメッセージにつけるようになると思います。そうすると
ITRON システムコールを直に使うことができる周辺核では、どのみち偽造する
ことはできると思います。

本当の意味でメッセージの送信元の身元をチェックするためには、ITRON のメッ
セージ管理を変更して、データとは別にメッセージ送信元を示すようにする仕
掛が必要でしょう(できれば、タスク ID に加えてマシンを示すような値 (マ
シン ID?) と組にした情報が必要かと思います)。

# こう考えていくと、ITRON というのは(善悪は別にして)組み込み機械用の
# OS なんだなあと思います。
# Mach のようにはじめからマイクロカーネルにすることを考えているような
# OS だと、メッセージを送受信する口はタスクごとに別々に管理するように
# なっていますから。。。(つまり口を示す値が同じでも、デバイスドライバ
# からは別のものに見える)

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