[b-free: 181] カーネルグルーブ集中ミーティング (3/25・ 26)議事録

真鍋 裕一 (NBG02534@niftyserve.or.jp)
Mon, 27 Mar 1995 23:26:00 +0900


TO:INET:b-free@iijnet.or.jp
SUB:カーネルグルーブ集中ミーティング(3/25・26)議事録

3/25・26両日に行われた、カーネルグループ集中ミーティングの議事録です。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
日時  1995/3/25 13:30〜21:00
3/26 10:30〜16:00
場所  品川区五反田文化センター
出席者 3/25 内藤 長谷川 磯山 木元 藤井 青木 藤永 小池 真鍋(記

    3/26 内藤 長谷川 木元 藤井 青木 藤永 飯島 大島 真鍋(記

配布資料 1.B-Free Project第二回カーネルミーティング資料
     2.B-Free Project第二回カーネルミーティング資料/2
     3.マネージャ間相関図とプロセス終了時のメッセージの流れ

[3/25]
●配布資料についての説明
 配布資料1.について、内藤さんから説明。
 配布資料3.について、木元さんから説明。

●今後決めるべき事柄について
 ユーザーから見えるB-FreeOSの具体象がわかる資料を作成することとした。
 決めるべき事柄としては、以下の発言があった。
1)OS起動から仮身一覧が立ち上がるまでのシーケンスを明確にする。
2)B-FreeOSとしての必要最小限のアプリケーションを決める。
3)ファイルシステム上のディレクトリー構成を決める。
 以上の3項目について、順番に議論する。その他の懸案事項として以下の項目
があげられた。 
・スワップ領域はパーティションに分割するか
・スケジューリング処理
・マルチスレッド対応とするか
・標準アプリケーションをどうするか
  −小物は標準アプリケーションとするか
  −CLIによるセルフ環境をどのように位置づけるか
・POSIX環境とBTRON環境をどのように同居させるか
・アプリケーションID管理はどうするか

●OSの起動手順についての検討
−−電源ONから仮身一覧の立ち上げまで−−

1)電源投入
2)IPL起動:ROMプログラムによりディスクの0~1ブロック(1024Byte)を読み
込み、実行を移す(FirstBoot)。
2)FirstBoot起動:FirstBootプログラムが2~129ブロック(64KByte)を読み込み、S
econdBootプログラムを実行する。
・起動時のパーティション選択プログラムについては、既存のプログラムを活用
することとして当面は考えない。
3)SecondBoot起動:
・16bit動作により32bit環境の作成
・32bit動作に移行
・カーネル読み込み(FD | HD)
・仮想記憶環境を作成し、仮想記憶モードへ移行
・カーネル(itron)のエントリーへ
 −システム初期化(itron)
 −自分自信がTskid=1となる様に情報を作成
 −実行モジュールの実行
  a.マネージャ群(BTRON環境で必要最小限のマネージャすべて=周辺核)
         (プロセス/メモリー/ファイル/デバイス等)
  b.デバイスドライバ(FD/HD/コンソール)
  c.初期化タスク(インタープリター)の実行
確認:デバイスドライバーは動的に読み込み/取外しが可能である。
追加:プロセスマネージャに、itronタスクをロード/クリエイト/スタートさ
せる機能をもたせる。
4)インタープリター実行:設定ファイル(STARTUP.CONF等)を読み込みながら、
その情報にしたがってシステムを起動する。
・ファイルシステムの接続
・外殻のロード
・デバイスドライバー(追加分)のロード
(懸案:デバイスドライバー類を収納するディレクトリーを作成して、そこにあ
るデバイスドライバーを読み込むようにできないか)
・デーモンプロセスの起動
・仮身一覧の起動

●デバイスドライバー処理について
懸案:デバイスドライバープログラムは固有空間を与えて読み込むか
 −ドライバー毎に固有の空間を与えるか
 −ドライバー全体に一つの固有空間を与えるか
 −カーネルの共有空間にロードするか

懸案:ファイルからの読み込みとスワップ処理をどの様に共存させるか。具体的
には、HDのデバイスドライバーがファイルからデータを読み込んでその内容を
メモリーに書き込む時点でページフォルトが発生すると、デッドロック状態とな
ってしまう。

懸案:デバイスドライバーは単一構造/階層構造のいずれを取るか

3/26
●配布資料についての説明
 配布資料2.について、内藤さんから説明。前日懸案事項の説明とまとめ。

●デバイスドライバープログラムをロードする空間
確認:共有空間(一つの仮想空間)にすべてのデバイスドライバープログラムを
ロードする方式とする。
問題点:現状ではコンパイラーの出力するコードが絶対アドレスを使用するため
、リロケータブルにロードできない。したがって、当面は各プログラムの絶対ア
ドレスを別途管理する方式を採用する。

●デバイスドライバー関連
確認:デバイスドライバーは階層構造を標準とする。但し、当面は単一型の実装
もありうる。
・既存のOSでは階層型の実績あり。(WinNT,HP-UX)
確認:ドライバー階層間、デバイスマネージャ〜ドライバー間のプロトコルを検
討する。
確認:ディスプレイカードドライバーとディスプレイプリミティブ(DP)間に
ついては固定のメッセージフォーマットを定義する。ディスプレイドライバー側
で展開が必要なメッセージに対してのみドライバー側で展開し、それ以外はDP
でビットマップに展開する。
検討:ソースコードを公開するので、DP自体を書き換えることができる。従っ
て、DPとディスプレイドライバーを一体化して、丸ごと入れ替える方式も考え
られる。(Xwindow方式)
懸案:DPとディスプレイドライバー/プリント用ドライバーをどのように分割
するのか。
確認:デバイスドライバー登録時の管理項目を決める
・デバイス名(hd〜(種別のみ))
・サブユニット数
・アクセス権(R/W/排他処理)
・メッセージバッファid
・デバイスの属性(キャラクタ型/ブロック型)
・メディアイジェクトの可否/NOWAIT
・メディアWriteEnableの属性
・デバイスのEnable/Disable
・ブロックサイズ
・最大ブロック数
懸案:ディスク入出力とスワップ処理のデッドロックを回避するための、情報の
受け渡し方法(ポインタで渡すかメッセージバッファを使って渡すか)

●その他
・メモリーマネージャ担当者を募集
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

訂正事項など有りましたら、御連絡ください。

真鍋 裕一(NIFTY-ID:NBG02534)