川合の「ぼやき」
気が向いたら更新します
このページは、OSASKを作っているときに感じたことをだらだら書いているだけです。
目次
2003/08/20号 「エミュレータOSの要件」
はじめに
今までエミュレータOSに関する記述が分散していたので、一つにまとめた。
ついでに分かりやすくるために書き足した。
これはOSASK-Wikiで下書きしていたものと同じものである。
「エミュレータOS」という語を最初に提唱した者による、今まででもっともまともなエミュレータOSの定義(みたいなもの)になっていると思う。
エミュレータOSは、以下のような性質をそなえたOSのカテゴリ名で、それらの性質の目的も以下に示されている。
「エミュレータOS」は固有名詞ではない。
エミュレータOSを作成するプロジェクトの代表例は、OSASK計画である。
エミュレータOSの語源と基本理念
今まで大きく普及したOSは、既存のソフトウェア資産を利用できるようになっていた(MS-DOS、LinuxなどのUNIX系OS、Windows、MacOS・・・)。逆に既存のソフトウェア資産を活用できない独自仕様OSのほとんどは普及や発展面で苦戦するのがほとんどである（もちろんわずかな例外はある）。
したがってOSを設計するならまずは既存のものとの互換性確保を第一に想定するのは当然だろう。
しかしそうなると、どうも似たり寄ったりのOSができるだけになりがちである。
これは結局既存のOSと大差なく、面白くないし、作る必要性も怪しくなる。
しかし今やエミュレータという技術があり、これを活用すれば新OSが既存のものとの互換性を意識した設計をする必要はない。
互換性の問題はエミュレータ技術を駆使して解決すればよい。
そうすれば、おもしろくて大胆な設計ができるはずである。
念のために書くが、エミュレータOSは特定のアーキテクチャとの互換性について意識しないというだけであり、どんな環境にも容易にマッチできるような汎用互換性については非常に意識する(たとえば徹底した仮想化設計など)。
また互換性維持に縛られなくなった設計の余地を効率の追求や他のOSとの連携などに振り向けるという要請もある。
これがエミュレータOSという語源であり、かつ、基本理念である。
ネーミングからしてエミュレータに関するものだけに関わる概念と思われがちであるが、それは違う。
川合がエミュレータ時代の未来のOSはどうあるべきかを考えた、川合にとっての理想OSの体系全体を指している(川合自身はより高望みをしていて、それはOSASK計画に盛り込まれているが)。
その辺を連想しにくいのでもっと他の名称にするべきだという意見は常にあるし、その件については全く同感だが、他によい名称にめぐりあえずここに至っている。
強調しておきたいのは、エミュレータOSにあっては、エミュレータというのは以下の要件を[達成する／思い付く]ための[手段／きっかけ]でしかなく、目的ではないということである。
エミュレータOSの要件
足枷だった互換性を気にしなくてよいということで、では何を追求するべきか。
エミュレータOSでは、単にエミュレータ技術を前提にするというだけではなく、その上で何を追求するべきかということも要件に含んでいる。
・徹底したネイティブAPIの仮想化
ネイティブAPIの設計において徹底した仮想化をしなければいけない。
たとえば、あるアプリケーションがあって、それはマシンの空きメモリに応じてテンポラリファイルの大きさを決めるような仕様だとする。
エミュレータOSでは、このような仕様のネイティブアプリケーションはありえない。
実際のハードウェアに応じてアプリ側が応対するというのは、アプリケーションが外環境に応じているということであり、そんなことはOSの仕事であると考えるのがエミュレータOSである。
エミュレータOSの理念にあっては、アプリケーションに都合のよい環境を確実に提供するのがOSの使命である。
だからFPUが使えるかどうかとか、MMXが使えるかどうかなど、そんなことを問い合わせる方法や必要がある仕様は、エミュレータOSのAPI仕様ではない。
アプリは問答無用でFPUが使いたければ使うし、MMXが使いたければ使うし、テンポラリが必要なら十分な大きさを確保するのである。
OS側はもしFPUが存在しないのならエミュレーションするし、MMXがないのならエミュレーションするし、メモリが足りなければ(仮想記憶などによって)エミュレーションするのである。
これによりアプリは「FPUがない場合の計算ルーチン」「メモリが少ないときの処理ルーチン」などというエミュレータ的コードを背負うことなく、シンプルでコンパクトになるだろう。
むろん、FPUがないときはOSがエミュレーションするよりも、アプリ側で「FPUがない場合の計算ルーチン」を使って計算するほうが一般的に高速に動作する。
だから、これを禁止するような要件があるなんて、駄目な仕様だと思われるかもしれない。
しかしそれは早とちりである。
意外に思うかもしれないが、アプリはFPUを使う演算ルーチンとFPUを使わない演算ルーチンの両方を実装していてもよい。
ただ、それが実マシンの状態によって切り替わるというのが駄目だと言っているわけである。
ユーザが選択するのであれば良い。
ユーザが選択するということは、実際にFPUがあるのにあえてFPUを使わないルーチンを使うとか、FPUがないのにFPU用ルーチンを使うということもありうるということである。
またユーザが選択するといっても、実行時に毎回ダイアログが出るというわけではなく、問い合わせAPIによって指示を仰いだり、設定ファイル等から読み取ってもよい。
これにより、たとえば仮にFPUを使わない計算ルーチンにバグがあっても、FPU用ルーチンを使うことでi486SXユーザがバグを回避できるなどというメリットもある(486SXはFPUを持っていないCPUなので動作は遅いだろうが)。
またFPU用ルーチンを使うとCPUによってはなぜか精度が悪いなんていう場合も、非FPU用ルーチンをわざと使わせることができるのである。
つまりせっかくアプリが両方のルーチンを持っているのだから、実際のハードウェア状態によってどちらを使うか勝手に決まってしまうのではなく、どちらを使うこともできるようにしよう、ということである。
・・・むろん先に書いたように、どちらか一方の処理ルーチンしか持っていなくてもよい。
エミュレータOSのアプリにあっては、ファイルの有無や状態なども外環境である。
これも仮想化しなければいけない。
アプリがOSに対して○○というファイルがあるか？という問い合わせはできない。
どんなファイルがあるかという問い合わせもできない。
○○というファイルを開けということはいえる。
実際にファイルがあるかないかに関わらず、OSがそのファイルへのアクセスを受理すればアクセスできるし、受理しなければアクセスできない。
それだけのことである。
仮にそのファイルを無事に開けたとして、はたしてそのファイルはもともとそこにあったのか、それともOSが急いで生成して適当に中身を書いてでっち上げたのか、それを区別するすべはない。
したがって、エミュレータOSのアプリにあっては、「ファイルがありません」というエラーメッセージはない。
「ファイルが開けませんでした」ならありうる。
実際にあるかないかはアプリには永久に分からないからである。
またアプリは"ABC"というファイルを開くように指示したのに、OSからは"DEF"というファイルのハンドルを渡されることもありうる。
しかしとにかくアプリとしては"ABC"を開いたつもりになるしかない。
他に情報が得られないので判断できない(する必要もない)。
APIのバージョンを問い合わせるようなファンクションもありえない。
ver.1では○○というファンクションを使い、ver.2では××というファンクションを使ってください、みたいなAPI仕様がありえないからである。
つまりOSに関する情報も外環境の情報であり、これを取得したりこれに応じてアプリの動作が変わるような必要は全くないのである。
(もしも相当することをやりたいのであれば)むしろ立場は反対であり、アプリは「今からver.2のファンクションを使うよ」と宣言するのである。
アプリがOSに合わせるのではなく、OSがアプリに合わせる。
当然のことながら、特定のハードウェアが不在かどうかとか、そういう問い合わせファンクションも存在しない。
ビデオカードが、あるビデオモードをサポートしているか、なんていう情報も取得できない。
現在の画面モードも取得できない。
独立して走っている他のタスクのことも知り得ない(シグナル等を交換し合って協調して動作しているタスクのことはもちろん知りうる)。
アプリにとってはありとあらゆることが不明であり、意識する必要の無いものである。
本当のことを検出する必要がないし、むしろ検出して動作を変更されたらそれは害でしかないので、検出する方法も極力つぶしておくのが望ましい。
このような徹底した仮想化のおかげで、エミュレータOSのアプリの抽象度は高く、他のOS上で実行するに当たっては、かなり少ない労力で可能であろう。
アプリ自身が根本的に環境に依存しないためである。
APIコールについては、INT命令などタスクごとにローカルな設定ができないものはふさわしくない。
タスクごとにAPIブリッジを使い分けたり、他のOSでブリッジを介して動作したりしやすいように、LDT上のゲートをコールするなどタスクローカルなものを使うのが望ましいだろう(もちろん、細工をすればINTやGDTもタスクローカルにできないことはないが、そんな苦労をしなくてもいい仕様のほうがより良いといえるだろう)。
・Win+VMwareなどはエミュレータOSとはいえない理由
Windows環境にVMwareなどを使ってLinuxアプリケーションを走らせる、という方法でのソフトウェア資産の継承は、エミュレータOSの目指すところではない。
その程度で我慢できるのなら、わざわざエミュレータOSなどということにこだわる必要はない(この手法は互換性の確保をアプリケーションに任せてしまうというものであり、エミュレータOSの思想と対立する考えかたである。
エミュレータOSでは互換性の解決はあくまでもOSの側の責任と考えている)。
エミュレータOSにあっては、WindowsにおけるDOSアプリケーションのエミュレーションのように(註：Windows MeやNT系ではエミュレーションがどうなっているのかよくわからないが、ここではWin95やWin98などの場合を想定して書いている)、それぞれのアプリケーションはネイティブアプリケーションと同じ操作方法で起動し、普通のウィンドウになり、ネイティブアプリウィンドウと自由にオーバーラップし、カット／コピーバッファも共有され、そのほか原則としてネイティブアプリと対等に動作するものでなくてはならない。
これさえ達成できれば、エミュレータ方式の詳細については、エミュレータOSという概念では特に規定されない。
・APIブリッジ・柔軟なファイルシステム・タスクセーブ
APIブリッジというのは、本格的なエミュレーションを行なうことなく、APIをフックするだけでネイティブAPIでサポートされないアプリを実行させる仕組みである。
エミュレータに頼るのは最後の手段ということにしておいて、APIブリッジで可能なものはAPIブリッジで実行するほうがいいだろう。
エミュレータといえば、たいていディスクイメージを実ディスクのように扱う機能がある。
そしてこれは実に便利でもある。
エミュレータOSではエミュレータで培われた技術を積極的に取り入れていくので、この手の機能は当然のようにOS側に実装される。
Linuxなどはディスクイメージをマウントすることができるが、これは有効な機能である(デバイスの仮想化)。
特定のデバイスでないと実行できない、なんていうことは許されない。
エミュレータOSはさまざまなOSのアプリケーションをエミュレーションするために、雑多なファイル属性をサポートする必要があるだろう。
したがってそのような柔軟性をそなえたファイルシステムをサポートする必要がある。
また任意のOSのメディアフォーマットを読み書きできる必要がある。
優秀なエミュレータには状態保存機能があるが、エミュレータOSはタスクセーブ機能を持っていなければいけない。
タスクセーブの方法はいろいろあると思うが、最低でも「タスクセーブしたことをアプリにまったく検出させることができない方法」をそなえなければいけない。
またアプリケーションタスクは必ずセーブできなければいけない(システムタスクなどはセーブできなくともよい)。
セーブしたタスクは容易に複製でき、また容易に同OSが走る別のマシンで実行できなければならない。
タスクセーブをどのように実装するかについての詳細はエミュレータOSという概念においては特に規定されない。
・他のOSとの共存を前提に
このOSはパーフェクトだから、他のOSと連携する必要などない！という態度は、エミュレータOSの設計とは無縁である。
あらゆる手を尽くして他のOSとの連携をはかり、共存共栄を目指す。
それがよい競争を生み、ひいては自分のOSの向上にも繋がるだろう。
具体的にはたとえば、そのOSをインストールすると他のOSがインストールできないなどというのは非常によくない。
それに加えて、相手OSの資産を活用するだけではなく、相手OSにとって自分のOSの資産が活用しやすい仕様を目指すべきである。
・・・このような姿勢を守っていれば自分のOSがバージョンアップしたときに、簡易なAPIブリッジ程度で自己の過去の資産を容易に引き継げるだろうという期待も持てる。
しかしだからといって、既存の仕様と似たり寄ったりのものを作ってもしょうがなく、技術的な必然性や妥当性があるなら革新的な仕様を採択するのは大変好ましい。
ここで言っているのは、他のOS上で実行しにくくするために故意に仕様を複雑にしたりしてはいけないということである。
OSを切り替えて使う人の利便を考えると、起動速度、終了速度が高速なことはとても望まれることである。
KHBIOSとの連携機能を実装すれば、そのOSの終了と同時にブートセレクタを経由せずに目的のOSを起動する機能などが実装できるので、前向きに検討する価値があるだろう。
・高効率の追求
エミュレータOSが他のOSの機能を有し(エミュレーションできる以上は結果的に同等以上の機能を持つことになる)、他のOSのアプリケーションやデータなどを利用できるということになれば、当然のことながら他のOSは機能的な優位性を誇ることはできない。
勝手な推論であるが、競争の結果として最終的にすべての汎用OSはエミュレータOSになるだろう。
そうなるとエミュレータOS同士の競争になる。
エミュレータOS同士ということであれば、お互いに機能的にはほとんど差がないことになる(互いにエミュレーション可能になるだろうから)。
そうなると、優劣を決めるのは効率になるに違いない。
だから、効率の追求もエミュレータOSの要件である。
効率というのは、できるだけ少ないバイト数で、できるだけ高速に実行するということである。
サイズについては当然のことながら、OSだけが小さければいいというわけではない。
ネイティブアプリケーションも小さくなるような工夫がなければ意味はない。
データも小さくなるような工夫をするべきである。
・・・なお、速さは低クロック動作でも快適に動作しうることにも直結するので、低消費電力という方面でも活躍できるだろう。
一プログラマとして助言すると、最初に適当に機能優先でプログラムを作って、そしてボトルネックをちょちょっと書き直せば、確かに十分な機能を有して十分な速度のソフトウェアを作ることはできるだろう。
しかし、これはサイズにおいては非常に不満な結果になる事が多い。
もし最終的にサイズも十分なものを作ろうということであれば、慎重な設計と何回かの作り直しが欠かせないだろう。
いい加減な設計をすると、その設計に思考が縛られてしまい柔軟な改良ができなくなることがある。
それゆえ、最初からサイズや速度などの効率に気を配りつつプログラムを書いていくのが結局は近道であると思われる。
もちろんそれでも作り直しは避けられないと思うが、作り直し回数は減らせるだろう。
サイズへのこだわりや起動速度などに配慮すると、必要なモジュール(ドライバなど)をオンデマンドでOSにアタッチする機能が必要だろうと思われる。
ついでにデタッチも付けよう。
そうすれば再起動なしにOSの構成を変更できるし、不要なリソースを食わなくできるし、起動も速くなる。
ということで、これらの機能も当然エミュレータOSの要件である。
・要件外の部分の具体例
OSを作る動機として革新的な外観の実現を挙げる人がいるくらいに、OSがどのようなユーザインターフェースをもつかは重要な問題である。
しかしエミュレータOSという概念としては、ユーザインターフェースについては一切規定しない。
ただ、既存のOSのアプリを動作させる以上は、同等かもしくはそれ以上の操作性は確保してほしいところである。
CUIでも、GUIでも、もしくはそれらを越える新しい操作スタイルであっても構わない。
OSやアプリケーションをどんなプログラミング言語で作成するかということについても、エミュレータOSとしては規定しない。
効率の追求をし始めるとある程度限定されるような気がするが、言語の進歩はまだまだいろいろと余地があるので、以上の要件さえ満たせるならなんでもよい。
OSASKのメモリレスアーキテクチャなどもエミュレータOSの要件ではない。
よりよい方法があるならそれを使ってよい。
・・・というかメモリレスアーキテクチャはどちらかというとOS設計におけるチャレンジである。
まだこれが既存の方法と比べて良いという実証が得られたわけではなく、したがって現段階の見解としては一般的な仮想記憶を使ったエミュレータOSがあってもよいだろう。
新OSが出てくるとたいてい話題になる、モノリシックカーネルかマイクロカーネルかということについても、エミュレータOSという規定の上ではノータッチである。
OS開発者がベストの道を見極めて進んでほしい。
なんといっても、OSの構成方法はモノリシックカーネルかマイクロカーネルのどちらかしかないというわけはなく、そんなことにこだわってもしょうがない気がする。
エミュレータOSの必要性・可能性
十分な機能を有して、過去の資産を活用でき、そして速くてコンパクトで消費電力も抑えられて、その上新たに産まれたソフトウェア資産の活用も容易になるだろうということであれば、いったい他にどんな点を付け加える必要があるだろうか。
・・・エミュレータOSによってもたらされる未来よりも輝かしい未来を他のOSが提供できるだろうか。
まさに次世代OSを名乗るにふさわしいだろう。
補足
もはや動けばそれで良いという時代は終わった。
単に目的の動作をするプログラムが書ければいいというわけではなく、それをどれだけうまく実現するか、という時代であろう。
エミュレータOSというのはそういう時代の要請を敏感に察知して、打ち立てられた概念である(やや先走りすぎて、提唱者さえも要求を満たすOSを作るのに四苦八苦しているが・・・笑)。
以上を読んでもらえれば分かると思うが、エミュレータOSにとってエミュレータドライバを揃えることは全体の要件からするとあまり大きなウェイトを占めない(むろんこれも必須条件であるので、無視していいわけではない)。
むしろその他に要求される要件の難易度が高く、設計・実装に当たっては多くの考察が必要だろう。
OSとして安定して動作するとか、マルチプロセッサに対応するなどということは原則として当然のことであり(効率を追求しておきながら、マルチプロセッサに対応できないなんてことは意味不明な方針すぎる)、そういう言うまでもないことはいちいち書いていない。
こういうことはわざわざエミュレータOSの要件に組み入れなくてもいいと思うので、組み入れない(きりがなくなる)。
これらはエミュレータOS以前の問題であったり、方針の一貫性に関する問題である。
エミュレータOSというと、たとえばWindowsアプリを動かすためのOSくらいに考えてしまう人がいるようだが、それはエミュレータOSの「おまけ」を中心に考えてしまっている危険性がある(もちろんおまけのほうが重要だという見解もありなので、それはそれでよい)。
エミュレータOSにとって一番重要なのは、ネイティブアプリである。
エミュレータOSにとって他のOSのアプリを利用するためのエミュレータドライバやAPIブリッジは、必ず提供はされなければいけないが、しかしOSから切り離し可能にもなっている。
エミュレータを使うのは、ネイティブアプリができるまでのつなぎであり(しかしまあ実際問題として全てのアプリを移植できるはずはないので、結局は永遠にエミュレータドライバも利用するだろうが)、よく使われるアプリはどんどんネイティブアプリに移植されていくだろう。
だから最終的にはエミュレータ性能はそれほどOSの評価には影響しない、と考える。
それゆえにエミュレータドライバ組み込み時の性能が落ちても、それはエミュレータOSとしてはそれほど問題視しないことにする(さすがに使用に耐えないのは困るが)。
それにもかかわらずOSASKはエミュレータドライバをできるだけ速く動かす、ということを目標の一つに挙げている。
これはOSASKが単なるエミュレータOS以上のものを目指していると解釈してほしい。
このページに関するお問い合わせは川合秀実(kawai@imasy.org)まで
OSASK計画のページへ戻る