KHBIOS :: OSASK計画

KHBIOSについて ^[1]

• (by K^[2], 2007.05.06)

KHBIOSとは？ ^[3]

• (1)KHBIOSはかつて「OSASKスタイル」を支援するための拡張BIOSでした。主たる目的はブートデバイスを増やすこと。そして副次的な目的として、TOWNSや98をも統合するような共通のBIOSだったら、OSを作るのが楽になるね、くらいの話でした。この場合のKHBIOSはブートセレクタのようにOSよりも前に起動します。
• (2)しかし後にOSASKのkhaba化（バイトコード化）が検討され、OSをkhabaで書いた場合の実行ランタイムとしての役割もKHBIOSが担うことになりました。この用途では、もちろん従来どおりOSよりも前に起動するという普通の使い方もありますが、そのほかにたとえばWindows上で動くバージョンも検討され、これを使うとWindowsのアプリケーションの一つとしてkhaba化したOSASKが起動することになります。イメージとしてはQEMUでOSASKを使うのとよく似ていますが、QEMUよりもリソースの消耗が小さく、高速なのが違います（QEMUより速くなるのはあくまで予定）。
• (3)「はりぼて友の会」の皆さんを活動を見ていると、FDへの書き込みや電源OFFや起動後の画面モード切替に少々苦労しているようでした。これを支援する機能がKHBIOSにあれば便利だろうと思いました。
• (4)その後K^[2]がXenに感動し、これを真似てOSASKを他の「はりぼてOS」ファミリーと同時起動できたら楽しいのではないかと考えました。どうせOSASKも「はりぼてOS」もメモリはあまりまくっているのです。CPUも空回りです。だから同時起動支援はおもしろそうです。ということで、これもKHBIOSの役割として押し付けることにしました。
• ということで結局、K^[2]がOSを作るに当たって、OSより下のレイヤでやってくれたらうれしいと思う仕事を何でも引き受ける存在がKHBIOSです。今も最終的なKHBIOSには(1)～(4)の全ての機能を作りこむ予定でいます。とりあえず今は(2)以外の3つを優先的に作っています。

KHBIOSに関する下書き （旧内容） ^[4]

• 書きあがったらosdev-jか「ぼやき」に移転の予定です。
• KHBIOSはOSASKを越えて利用してもらいたいと思っているので。
• ちなみにこの文章を書いているのは、川合(K^[2])です。

• Ｑ：KHBIOSはブートセレクタとはどうちがうの？
• Ａ：思想が違って、目的が違って、そして結果的に動作も違います。
  • ブートセレクタの目的は単純明快で、HDDに複数のOSをインストールしたので、そのうちのどれをブートさせるか選ぶ、というものです。ブートセレクタは、ユーザにとっては立派な存在ですが、OSからはできるだけ検知されないように設計されており、その努力のおかげで、ほとんどのOSが各種のブートセレクタに対応できています。これを逆に考えると、OSに感知されにくくすればするほど、良いブートセレクタだということになります。
  • KHBIOSの目的は違います。KHBIOSはHDDに限定せず、全てのストレージデバイスからの起動を可能にすることを目的にしていて、その手段として全てのストレージデバイスを共通のファンクションで読み書きできることも達成しようとしています。そうすれば、この共通のファンクションを使ってブートするようなOSを作りさえすれば、FDDもHDDもCD-ROMもCFなどのメモリカードも、PDやMOなども、はてはネットワークブートも可能になるわけです。
  • KHBIOSのファンクションは普通のBIOSのファンクションとは呼び出し方が違います。というのは、同じにする必然性がなかったからです。同じ方法で呼び出せるようにすれば従来のOSがそのままKHBIOSに対応すると思われがちですが、それは違います。たいていのOSは最初は素直にBIOSを使ってブートしますが、途中から自分の32bitドライバを使ってブートを継続します。そうなると、BIOSを使ってHDDから起動していると思いこんでいるOSは実際はHDD以外から起動しているということに対応できず、起動に失敗します。
  • ということでKHBIOSの仕様をBIOSコンパチにする必然性はないと考え、もっと単純で拡張性のある形式にしました。したがってKHBIOSを使うには当然OSをKHBIOS前提に書き直す必要があります。つまり、KHBIOSはOSに認知されなければ始まらないのです。したがってKHBIOSではKHBIOSだけで何もかも完結してしまうのではなく、OSと連携して各種の目的を達成します。
  • KHBIOSでは用が済んだらOSから見えなくなることも重要ですが、OSが希望すればずっと居座る機能もあってこれも重要です。何のために居座るのかというと、OS側が用意していないストレージデバイスのサポートをすることもありますが、リブートの支援も行ないます。これは、KHBIOSに指示して他のデバイスや他のパーティションからブートし直せるわけです。
  • KHBIOSではかっこいいメニューをKHBIOSが提供するという考えはありません。なぜならそういうことこそOSがやればいいだろうと考えているからです。KHBIOSはひたすらすみやかに陰でブートすることだけに専念します。かっこいいメニューやかわいいメニューは人によって好みがあるでしょう。それをプログラマブルにしたすごいブートセレクタはきっと存在するでしょう。しかしKHBIOSはそういう流動的な部分こそOSやOS上で走るアプリに担ってもらいたいと考えています。そうすればかっこいいセレクタのプログラミングに当たっては、KHBIOSが提供する貧弱なファンクションだけではなくOSが提供する豊富なファンクションや開発環境を利用できるでしょう。先のリブート用のKHBIOSファンクションの存在は、まさにその思想を反映したものです。
  • こんな風に考えることもできるかもしれません。OS作者がブートセレクタを独自の視点を生かして作ったのがKHBIOS。普通のブートセレクタのプログラマーはOS作者ではなく、そのためOS作者に迷惑をかけないように多大な努力を払い、OS側の協力が必要な機能は実装不能として仕様から外してしまうのでしょう。僕はOSASKの作者ですので、自分の目的を達成するに当たって、何をOS側の機能にして、何をKHBIOS側の機能にするのがベストなのかを考えることができます。結果的にKHBIOSは各種のOSとよりよい関係になれるのではないかと思っています。
• Ｑ：特定のキーを押したらメニュー用のOSが起動する、みたいなことはできますか？
• Ａ：可能ですが、多分これはあなたの想像とは違う手法で実現します。
  • KHBIOSでは、とりあえず最低限必要なデバイス以外は気にしないことにします。つまりストレージデバイス以外のものは見ません。キーも、マウスのクリックも、そのほかのものも見ません。キーを見るとなると、PS/2なのかUSBなのかとかが問題になり、そのためにドライバを書く必要が出てきて、KHBIOSがだんだん大きな仕組みになってくる可能性があります。そしてそれは僕の望まない方向です。KHBIOSはOSとの分業を意識していまして、複雑なことはOS側でやってほしいと考えているわけです。
  • こんなOS（もしくは汎用OS＋アプリ）を作ったらどうでしょうか？・・・ブートしたらすぐにキーボードを見て、特定のキーが押されていなければAというデバイスからブートします。もしキーが押されていれば、メニューを表示して選択させます。そしてこのメニュー用のOSをまっさきにKHBIOSからブートするようにしておきます。
  • この方法はもちろんKHBIOS以外にもメニュー用のOSを経由するのでほんのちょっとだけブート時間が増えるでしょう（KHBIOS対応版OSASKとかを改造して使えば起動時間は気にならないレベルに減らせるでしょう）。これは欠点です。しかしこの方式にすれば、KHBIOSを拡張することなくキー以外のデバイスにも対応できますし、その他どんな拡張も可能でしょう。そしてKHBIOSはキー入力を見張らなくてよくなるので、常に最小時間で目的のOSをブートできます。
  • もちろん、KHBIOSにストレージデバイス以外のデバイスについても統一的なインタフェースを提供するという使命を与えることはできますし、それはそれでいい考えだと思います。そういうバージョンのKHBIOSを作ることがあれば、KHBIOSにPS/2キーボードドライバやUSBキーボードドライバを付加可能にするでしょう。しかしその場合でも、それらのデバイスの状態でブートシーケンスを変える仕組みをKHBIOSに導入することはしないと思います。そういう高度なことはOS側にやってほしいです。本質的にOSにできないことだけをKHBIOSがやる、というイメージでしょうか・・・。
  • KHBIOSはユーザが設定したとおりの順序でストレージデバイスをチェックしていき、ブート可能なものがあったらブートするだけです。僕の想定するKHBIOSの利用形態では、そもそもメニューという発想がありません。使いたいOSをドライブにセットして電源を入れます。それだけです。HDDに複数のOSを入れるという用法からしてKHBIOSっぽくないです。もちろん、KHBIOSっぽくなければいけないということはありませんが。
  • 仮にHDD内にOSを入れたとしても、僕ならメニューの代わりに、HDD内のOSASKを起動するCF、HDD内のLinuxを起動するCF、HDD内のMonaを起動するCF、みたいなCFをそれぞれ作って、どのCFをセットするかで起動するOSを選ぶでしょう。メニューはいちいち入力しなければいけないので僕には面倒です。CFなどのメディアなら同じOSを連続して数回使う間はいれっぱなしにしておけばいいわけです。僕は起動時間を短くすることに執念を感じているので、キー入力で起動が遅くなるのが耐え難いのです。こんなのは僕だけかもしれませんので、メニューが好きな人はメニューを使ってください。
  • なおKHBIOSの設定メニューなどもKHBIOS自身は持っていません。設定用のファンクションや設定確認用のファンクションがあるのみです。これはつまり設定用のOSを作るか、設定用のアプリを書く必要があるということです。これについては、あまりかっこよくないものでよければ、僕が提供します。そのうちいろいろかっこいいやつが出てくるでしょう。
  • もし僕がハードウェアやBIOSを設計する機会に恵まれたら、まずPCのストレージデバイスはPCカードのみにして、他のハードウェアはオプショナル扱いにします。そしてBIOS-ROMの中にKHBIOSを入れてしまいます。BIOSはブート時に16MBのみのメモリチェックを行ない、残りは容量チェック程度しかやりません。またHDDやCD-ROMブートの順番が回ってこない限りこれらの初期化を待たずにCFなどからのブートを開始してよいというオプションをBIOSに付けます。BIOSメニューはCFの中に入れて、そのCFをセットしてブートすることでメニューが出るようにします。・・・これでBIOSはメモリチェックに時間をとられない、HDDやCD-ROMの初期化完了を待たなくていい、BIOSメニューに行くかどうかのためのキーも見張らなくていい、の3条件が揃って電源投入の瞬間にCFからのブートが可能になります。詳しいメモリチェックなどは、BIOSメニューCFを入れると可能になります。

• (編集中)