KHBIOS関係のメモ
(1) KHBIOS vs GRUB
(2) KHBIOS vs EFI
(3) リアルタイムBIOS
- KHBIOSはリアルタイムOSからも利用されるようなBIOSを目指す（要するに各OSのデバイスドライバの下請け的存在でありたい）。そうなるためには、BIOSが全体的にリアルタイム性を満たしている必要があるだろう。ということで、これをリアルタイムBIOSということにした。
- これは結局OSASKがきちんとしたリアルタイムOSへ進化するための下準備でもある。
- KHBIOSのファンクション呼び出しは、基本的にはOSASKのGUIGUI00のAPIのような、構造体の連続になる予定である。その中には、リアルタイム性を記述するための構造もあり、それらで目的の機能を修飾することで、リアルタイム性をBIOSに対して要請できる。
- KHBIOSが要求するリアルタイム性は次のようにまとめられる。
- 優先順位情報：
- 以下のリアルタイム性に関する記述がどのくらいの優先度を持っているのかをKHBIOSに伝える。KHBIOSはこの優先順位を参考にして各種I/Oのスケジュールを行う。
- 希望完遂時刻：
- この時刻までに指定された機能を実行し、正常終了かエラーなのかを返してほしいという意思表示。
- タイムアウト：
- この時刻までに指定された機能が実行できなかった場合、もしくはできる見込みが全くない場合、実行しない。エラーが帰る。
- スケジュール予約：
- 具体的な作業は決まってないんだけど（たとえばどこのセクタを読むかは分からないんだけど）、とりあえずこのデバイスに対してこんな感じのことを優先順位なにがしで何時ごろにやる予定なので、スケジュール上で確保しておいてほしいなという機能。これはもちろん作業時間を予約する機能なので、処理したいセクタ数すら分からないというのはダメ。
- リアルタイム例外：
- KHBIOSからコールバックする場合があるかもしれない。その場合、規定の時間内に処理を終えて帰ってこなくてはいけない。このとき、割り込み禁止（厳密にはCLIという意味ではなく、KHBIOSに対して割り込み的な処理を保留しろという指示）中に規定の時間を迎えると、なんとリアルタイム例外という（仮想的な）例外が発生する。KHBIOSとしては、そのプログラム（というかOS）は問題があるので異常終了させようとする。
- だからOSは時間を気にするか、もしくは「自分はかなり時間を使うよ」と事前にKHBIOSに伝えておかなければいけない。KHBIOSとしては前もって言ってさえくれれば、特に不満はない（それを前提にスケジュールするから）。指定しておいた時間よりも早く終わる分にはかまわない。
- リアルタイムイベント：
- キー入力やPITのタイムアウト、その他さまざまな割り込み処理にはそれなりの優先順位をつける必要がある。また実際には状態変化の割り込みがサポートされていないようなデバイスであっても、KHBIOSが適切な時間間隔でセンスし、変化があれば通知する。
- 基本的にこういうイベントは、OSASKのシグナルボックスのようにバッファにたまるだけである。つまりOSに直ちに知らされるわけではない。バッファがある程度たまってくるか、もしくはそれぞれのイベントに対する最大レイテンシ（事前に各OSがKHBIOSに対して設定しておく）を超えそうになるとOSに知らされる（＝OSが起こされる）。
- 状態変化があり次第連絡するという指定には有効期限がある。だから有効期限が近づいてきたら延長したほうがいい。有効期限を設けた最大の理由は、OSが暴走して反応がなくなったのに、つまりもはや処理される見込みのないイベントを、バッファにため続けるのがバカらしいと思うからである。
- 補足：
- とにかく早くやってほしい場合、希望完遂時刻は現時刻にしてしまう。
- ほとんどKHBIOS呼び出しは非同期で実行される。まず希望時間内にできそうかどうかが判明した時点で、それを通知してくる（そのときはできそうだといわれても、より高い優先順位の要求がくれば、やっぱり間に合わなくなりそう、という通知が来ることはある）。
- 予約を申請したときに取れないといわれても、優先順位の高いものや同じものがキャンセルされたりすれば、再度申請したときには予約が取れることだってある。
- 音楽再生やビデオ再生の場合、そのデータが必要になる時刻は前もって分かっているし、それより前にデータが準備できても実はメリットはない。だからそういうのは希望時間内の範囲で後回しにして、他の要求を（たとえ優先順位が高くなくても）片付けることができる。
- ネットワークパケットのやり取りにも、以上の制御がかけられるようにしたい。もしIPではできないということであれば、かつて検討していた「OSASKネットワーク」上でのみ厳密に適用される、っていうのでもかまわない。・・・もしこれができれば、たとえばyoutubeで再生中にどこかのOSのサイトからISOをダウンロードしてもコマ落ちしないし、さらにネットワークゲームをすることだってできるかもしれない。その際、もし十分な帯域を得られそうになければ、実際にゲームが始まる前に「ゲームプレイに十分な帯域が予約できませんでした」って言うことだって可能だろう。・・・それでISOダウンロードの完了希望時刻を3時間後とかに訂正すれば、帯域に余裕ができてネットワークゲームができるようになるわけである。・・・もしOSやBIOSにリアルタイム性がなければ、ゲームをプレイして帯域不足でいきなり動きがおかしくなって、パーティに多大な迷惑をかけてしまい、今度ラーメンをおごることになってしまうかもしれない。
- BIOSの命令体系が、(1)命令内容の指示、(2)命令実行開始のトリガ、の2段に分かれるべきかもしれない。トリガはトリガ命令で実行を開始するというよりも（そういう場合もあるけど）、実行開始時刻の設定や追い越し禁止命令の設定など、つまり開始条件の設定をすることになる。・・・話が前後したが、要するにすべてのコマンドに対し、「いつまでに実行してほしい、されるべき」という情報だけはなく、「いつまでは実行するな」という指示も必要だろうと思うわけだ。もしリアルタイムBIOSでこれができない場合、OSは実行しても良い時間帯になってからコマンドを送ることになるが、これだと時には間に合わなくなることがあるかもしれない。しかし事前に言ってもらえれば、準備をすることができて、間に合わせることができるかもしれない。
こめんと欄
- 希望完遂時刻やタイムアウトにもいろいろあるのかもしれない。たとえば、アクセスがスケジュールできたかどうかを通知するだけでも多少の時間はかかるわけで（特に優先度があまり高くない場合）、その時間に対しても希望時刻やタイムアウトがあるべきなのかもしれない。 -- K 2007-10-14 (日) 19:21:42
- ネットワークの話ですが、ダウンローダーの中には帯域制限ができるものがあります。工夫すれば現在の技術でも、帯域に余裕を作ることは可能です。それから、ダウンロード等しながらゲームをするときは、メモリ管理も大変そうなんですよね…では。 -- くーみん 2007-10-15 (月) 02:34:57
- ダウンローダの帯域制限について。それは各ダウンローダが手動の設定などによって自粛することによって実現している技術であり、優先度の高いものがダウンローダの帯域を減らすように自動的に調整してくれているわけではないと思います。つまりそういう優秀なダウンローダとリアルタイムOS（というか帯域制御が充実しているOS）の違いはそこなんだと思います。 -- K 2007-10-17 (水) 06:53:35
![[K Wiki]](k.jpg "[K Wiki]")
