・LowLibは、デバイスドライバマネージャの用意しているメッセージバッフ
ァのサイズ以上の要求を発行してはいけない。(不可能)(LowLib内で分
割して発行する)
デバイスへの書き込み(デバイスドライバへ送るメッセージ)
struct {
WORD dd; // デバイスドライバマネージャ管理情報
// デバイスドライバはこの値を使用せず,応答メッセージの
// 先頭に登録する
LONG start; // デバイスの先頭からの位置(物理ブロック単位)
LONG size; // 書き込み量(物理ブロック単位)
BYTE dt[0]; // 書き込むデータ
};
・デバイスドライバマネージャは、メッセージバッファの空き容量を検査し、必要
が有れば、データを分割して要求を送る。(前回のミーティングで、ブロック単
位に分割して要求を発行するというように発言したが、それは取り消します。デ
バイスドライバが1ブロック単位での書き込み要求しか受け取りたくない場合に
は、メッセージバッファのサイズを調整することによりデバイスドライバ主導で
実現可能となります)
デバイスへの書き込み(デバイスドライバマネージャへの応答)
struct {
WORD dd; // デバイスドライバマネージャ管理情報
WORD errcd;
WORD errinfo; // エラー詳細情報
LONG a_size; // 実際に書き込んだブロック数
};
デバイスへの書き込み(LowLibへの応答)
struct {
WORD errcd;
WORD errinfo; // エラー詳細情報
LONG a_size; // 実際に書き込んだブロック数
};
デバイス制御(ctl_dev)
struct {
ID pid; // システムコールを発行したプロセス
WORD dd; // デバイスディスクリプタ
UWORD cmd; // 制御コード(デバイスドライバ依存)
WORD len; // パラメタのバイトサイズ
BYTE param[0]; //
};
デバイス制御(デバイスドライバへ送るメッセージ)
struct {
WORD dd; // デバイスドライバマネージャ管理情報
// デバイスドライバはこの値を使用せず,応答メッセージの
// 先頭に登録する
UWORD cmd; // 制御コード(デバイスドライバ依存)
WORD len; // パラメタのバイトサイズ
BYTE param[0]; //
};
デバイス制御(デバイスドライバマネージャへの応答)
struct {
WORD dd; // デバイスドライバマネージャ管理情報
WORD errcd;
WORD errinfo; // エラー詳細情報
};
デバイス制御(LowLibへの応答)
struct {
WORD errcd;
WORD errinfo; // エラー詳細情報
};
デバイスのアクセスモード変更(chg_dmd)
struct {
ID pid; // システムコールを発行したプロセス
TCODE dev[8]; // デバイス名(ユニット名)
UWORD mode; // 新しいアクセスモード
};
デバイスのアクセスモード変更(LowLibへの応答)
struct {
WORD errcd;
};
デバイスの管理情報の取り出し(dev_sts)
struct {
ID pid; // システムコールを発行したプロセス
TCODE dev[8]; // デバイス名(ユニット名)
};
デバイスの管理情報の取り出し(LowLibへの応答)
struct {
WORD errcd;
DEV_STAT stat;
};
論理デバイス名の取り出し(get_dev)
struct {
ID pid; // システムコールを発行したプロセス
WORD num; // デバイス番号
};
論理デバイス名の取り出し(LowLibへの応答)
struct {
WORD errcd;
TCODE dev[9]; // ユニット名
};
・正常終了した場合にはerrcdにサブユニット数が返却される
登録済みデバイスの取り出し(lst_dev)
struct {
ID pid; // システムコールを発行したプロセス
UWORD ndev; // 返却するデバイス情報数
};
登録済みデバイスの取り出し(LowLibへの応答)
struct {
WORD errcd;
DEV_INFO info[0];
};
・正常終了した場合にはerrcdにデバイス情報数が返却される
イベント通知先の変更(今の所実装の予定なし)
struct {
WORD mbfid; // イベント通知先のメッセージバッファ
};
・デバイスドライバはデフォルトでデバイスドライバマネージャにイベントを送り
ます。しかし、デバイスが再登録されるとイベント通知先変更のメッセージが送
られますので、それ以降は、このメッセージで指定されたメッセージバッファに
イベントを送ってください。(ここで指定されるメッセージバッファは、再登録
したデバイスドライバのメッセージバッファです。従って、再登録するデバイス
ドライバでは、デバイスイベントを処理できなければいけません)
イベントの通知(デバイスドライバマネージャへの通知)
struct {
WORD kind; // デバイスイベント種別(詳細はデバイスドライバに依存)
WORD devno; // デバイス番号
};
・デバイス番号は、デバイス登録時に返却された値を指定してください。
イベントの通知(ユーザープロセスへの通知)
struct {
WORD kind; // デバイスイベント種別(詳細はデバイスドライバに依存)
WORD devno; // デバイス番号
LONG time; // イベント発生時刻
};
・デバイス番号で指定されたデバイスをオープンしているプロセスがいなければ、
発生したイベントは無視されてしまいます。
・デバイスが複数のプロセス(タスク)からオープンされている場合は、全てのプ
ロセス(タスク)にイベントが通知されます。
・キーボードイベント、ポインティングデバイスイベント、FD挿入イベント等を
処理するためには、デーモンプロセスが動作している必要があります。
前回のミーティングで聞き漏らしているのかも知れませんが、いくつかの疑問点があり
ますので、書いておきます。
・仮想メモリマネージャからのスワップ要求を優先的に処理するためには、メッセージ
バッファの属性に「優先度順のキューイング」をサポートしてもらいたいのですが、
これは可能でしょうか?
・上記に関連するのですが、ファイルマネージャ経由でスワップ要求を受け取る場合に
は、タスクの優先度順で処理することは不可能?(ファイルマネージャの優先度にな
ってしまう)なので、他(タスクの優先度以外)の優先度を指定するようにしてもら
いたいのですが、これは可能でしょうか?
・メッセージバッファ用のメモリがスワップされることが有りうるとすれば、(デバイ
スアクセスの)システムコールの処理中にページフォルトが発生する可能性がありま
すが、メッセージバッファ用のメモリは常駐になっているのでしょうか?