design011 :: OSASK計画

OS開発の方向性

• (by K, 2009.01.03)

(0)

• これは当初「川合のぼやき」に書こうかどうか迷った内容のものを書くことにしたわけだけど、ここは僕のホームページではなくOsaskWikiなので他の誰が書いてもいいものだと思う。
• ただこのシリーズの趣旨としては、OSASKの設計に関する話を書いているので、他の人が書く場合もそれには準じてほしい。で、僕以外の人がOSASKの設計に関する話を書くなんてことはまずないと思うかもしれないけど、そんなことはなくて、たとえばこういう考え方のもとでこうしたらどうかという提案はできる。
• 基本的に一つの話題に1ページ使ってしまうので、ちょっとした提案であれば、OSASK-MLやimpressionsを活用してもらうほうがいいと思う。

(1)

• これを読んだ（これに限らず.mjtさんの日記は興味深い話題が多いと思う）。
  • http://d.hatena.ne.jp/mjt/20090103/p3
• この記事のタイトルは「OS開発の今後」となっているけど、これは必ずしも一般的なOS開発を指しているわけではなく、.mjtさんが望んでいるOSの開発、もしくはそれに類するOSの開発のみに当てはまることだと思う。それを踏まえて読むと、なかなか面白い。
• .mjtさんにとっては、「OSを作る＝新しいファイルシステム（オブジェクト環境）を作る」ことなので（それが目的なので）、この話になるのだと思う。・・・めんどくさいので、いっそのこと引用してしまおう。

  OS開発のマイルストーンを現代的に定義するとするなら :
   1.libcをどうにかして、自分のオブジェクト環境の中でgccをコンパイルする
   2.mingwのbashやm4等各種ツールを自分のオブジェクト環境の中で動かす
   3.Xenの上で動くカーネルを作る
   4.(Xorgを移植する)

• この話を読むと分かるとおり、独自のファイルシステムを作って、そこで既存のアプリケーション（gccやbashやm4）を動かすことになっている。つまり独自のアプリケーションを動かすことは主たる目的ではないのだ。カーネルをXen上に構築することで分かるように、ドライバを作ることも目的ではないのだ。またXを移植するというところで分かるとおり、独自の新しいウィンドウシステムを作ろうという気もないらしい。・・・僕はそれを批判したいわけじゃない。OSを作る目的は人によってさまざまだ。ファイルシステム重視で作るというのは非常に有力な一つの候補だし、それは他の目的と比べてなんら劣ってなんかいない。僕が今言いたいのは、でもそれでOS開発全般を語ったことにはなっていないということを指摘しておきたいだけだ。
• 独自のウィンドウシステムを作りたくてOSを作る人もいる。独自のAPIを作りたくてOSを作る人もいる。とにかくカーネルを書きたいという人もいる。カーネルなんてその辺から流用してしまえばいいという人もいる（L4カーネルを使って独自OSを作るとか）。デバイスドライバを書くのが楽しくてしょうがないという人もいる。

(2)

• さてここからがむしろ本題なのだけど、じゃあ僕はどうなのか、OSASKはどうなのか。それを整理してみようと思う（というかそれがなければこの話題はOsaskWikiにふさわしくない・・・笑）。そしてそれをやってみたら、なかなか興味深い分析ができそうな気がする。
• 僕はとにかく究極的に効率のよい状態がほしい。古いPCも新しいPCもその能力を余すことなく出し切れている状態がいい。特に古いPCが能力を出し切っていないのに、つまり本当はまだまだ現役でやれるのに、それなのに無能力の烙印を押されて破棄されていくのは嫌いだ。
  • 参考：design007の(1)
• そういう「状態」を生み出すにはどうしたらいいだろうか。それには効率のよいOSと効率のよいアプリと効率のよいドライバと効率のよいウィンドウシステム・・・などが必要だろう。そして最初僕はOSから作ろうと考えた（全てを同時に作ることはできない、どれかからやらなければいけないのだから）。アプリは後回しにしようとした。それが初期のエミュレータ重視路線でもある。
• しかし実際にOSから作って分かったことがあった。実は全てを同時に作るウルトラC的な方法があったのだ。というのは、つまりアプリはコミュニティの人でも手が出しやすいし、しかもそれは十分に既存のアプリよりもいいものなのだ（多分僕が作るよりもいい・・・というのは、確かに僕が作ったほうがより効率を高められることもあるけれど、でも僕はアプリのアイデアは貧困だから、僕だけがアプリを作ってもろくなものじゃない）。・・・そういうことなら、最初に作るべきはOSじゃない。APIだ。OSとアプリの接点であるAPIさえ決まれば、OS開発班とアプリ開発班は別々にそして同時並行的に開発できる。OSから作っていたのでは、OSに実装していない機能のAPIは作れない。
• そう考えれば、今の「ぐいぐい01」の流れはとても自然だ。僕が今やっていることはまさにOS開発に先行してAPIを決めることだから。OSASK-HBよりもabcdwのほうが明らかに先行している。APIの良し悪しはもちろんアプリが小さくなるかどうかだ。非常に分かりやすい判断基準である（それがいいかどうかは別にして）。そして成果が上がってきていることは、GUIGUI01​/memo14の表などを見ればはっきりと分かる。
• 僕はとにかく効率のよい状態がほしい。そして効率を究極的にまで高めるためには、結局全ての部分を高効率なものに置き換えなければいけない。ファイルシステムだけ作り変えればいいわけじゃない。とりあえずここまででAPIとアプリについては解決できたとしよう。それでもドライバやカーネルやシェルやファイルシステムやウィンドウシステムや・・・それこそいくらでもある。.mjtさんの提案のように、適当に既存のものを流用できるのならしたいくらいだけど、そういう流用は結局は「とりあえず動いただけ」になってしまうことが多く、とても高効率とはいえない。動くだけでいいのならそもそもOSなんか作る必要がないのだ、僕の場合は。OSを作ることそのものは目的じゃないから、そんな効率の低いもので我慢できるのならわざわざOSを作るまでもなく、Windows上やLinux上でefg01していれば用は済む。
• そう考えると、なかなか道は長くて遠くて険しい。でも他にやりようがないから仕方ない。ほしいものはほしい。いくら大変そうでも、それを理由に自分にとって必要のない別の何かを作る気にはならない（大変だからあきらめるということはありえるかもしれないけど）。

(3)

• なんと.mjtさんが早くもお返事を書いてくれた（忙しいのにどうもありがとうございます）。
  • http://d.hatena.ne.jp/mjt/20090104/p1
  • http://d.hatena.ne.jp/mjt/20090104/p2
• いい話題だと思うので論点を整理してお返事しようと思う。まず順序を逆にしてp2のほうからいこうと思う。例によってまた引用から。

  要するに、
  
    あのリストは、「今後近代的なPCで動作するOSを製作するために必ず通る道」を挙げたもので、
    デバイスドライバを作るとか、Windowsystemを作るとかはこれらの『後』に来ることを想定している。
  
    もちろん、あのリストを誰かが代表して埋めて、フレームワークとして共通化するのも
    方向性としては想像できる。
  
    コンパイラがself-hostingにならなければならない理由は、Linuxのカーネル以外に依存する
    デザインにするとHypervisorとLinuxユーザランドの両方に依存してしまうため。
    また既存のソフトウェアの流用を非常に難しくする。

• 要するに.mjtさんとしては(1)のリストは自分の想定しているOSの開発だけに適用されるものではなく、OS開発一般に適用されるものだとしている（＝僕の解釈は違うと指摘している）。この主張の前にp1のほうにも意見があるので、本当はそっちを先に解説するべきかもしれない。でも僕はあえてこの順序でお返事したい。でも僕はp1の内容に触れるような反論は書かないし、読み手にもp1を読んでからここを読むことを期待している。
• 何から作るべきかということに関して言えば、僕としては別に何から作ってもいいじゃないかと思う。IPLから作りたい人はいるし、でも最初はGRUBでもつかっておけばいいじゃんという人もいる。それをあえてこの順序で作るべきだとしなければいけないのがよく分からない。・・・僕の経験から言えば、自分が作りたいところから作るのが一番うまく行く気がする。.mjtさんはもちろんファイルシステムの改良がOS開発の主たる動機だから、最初にファイルシステム関係を作りたいと思うのはとてもよく分かるし、僕もそうするべきだと思う。でもだからといって、他のOS開発者が何を重要に思うべきかとか、何から作るべきだとまで言及してしまうのは、やっぱり勇み足なんじゃないかと思う。・・・でもこれは自分のOS設計に強い確信をもっている証拠でもあるから、まあ勇み足しちゃうくらいがちょうどいいといえばちょうどいいんだけど（笑）。そういうことを考えると、僕がここでこんなツッコミをするのはいかにもジジくさい。黙って心の中で「若くていいのう」と微笑むべきだったかもしれない。
• あとコンパイラの話も、結局は「既存のソフトウェアの流用」のためであって、既存のソフトウェアの流用にあまり興味がなければ（たとえばOSASKのように作り直す気満々なら・・・笑）結局必然でもなんでもない。結局.mjtさんの論は、「○○ではないのは現実的ではない」という隠れた前提がたくさん積み重なっていて、それを全て満たしたOSのみにしか当てはまらないと思う。僕としてはそういう一方的な想定を置くことは良くないと思っている。当たり前そうに思えることを疑ってみる人が少しは必要だから。
• さて次はp1のほうを。まずはやっぱり引用。

  API or Language(なぜAPIでなくてファイルシステムなのか)
  
    個人的には、究極に効率的なシステムのためにも、APIを決めることよりも「記述環境」を
    作ることに意義が有ると考えている。
  
    システムとして出荷されたときのバイナリサイズよりも、実行時に占めるメモリサイズのほうが
    多分重要で、そのためには必要な部分だけをロードするといった対策が必要になる。
    出荷されたときのバイナリサイズにしても、部品の共通化を進めるのは良い影響を与える。
  
    (少なくとも、僕の知識ではAPIコールの効率性とシステムの効率性を関連付けられない)
  
    そもそも、現代的なシステムではプログラムよりもデータの方が圧倒的に大きな存在感を占めている。
    メモリからキャッシュへのコピー、データの配列、そのほかのI/Oがシステムの速度を決定付けている。
  
    (もし必要なら、)良くデザインされたファイルシステムはこの側面にアプローチできる。
  
    ただ僕の主張としてより重要なのは、APIはプログラマにしか触れないけれどファイルシステムは
    ユーザ全員が触るという点で、より端的に表現すれば「多くのプログラミングは
    本来プログラムの外部で行われる必要が有る」。
  
    一つ一つのプログラムを小さくすることよりも、プログラムの数そのものを減らした方が
    効率的に思える。

• 最初の段落（個人的には～）と、最後から2番目の段落（ただ僕の主張として～）については、僕もおおむね同感だ。つまりたとえばプログラマでない人でも（従来のOSではプログラミングしなければできなかったような）高度な操作が簡単にできるようなOS（というかシステム？）こそ希求されるべきだというのは、.mjtさんからの以前からの主張だし、それはその通りだと思う。そしてその実現のためにファイルシステムを作り変えたほうがいいのではないかという主張も（ファイルシステムからオブジェクト管理システムにアップグレードする感じ？）僕の大いに支持するところだ。
• しかしそういうシステムをたとえばFATファイルシステム上に絶対に構築できないかというと、そんなことはないと思う。カーネルだって実はLinuxやITRONとかを使っても別にできないことはない。どちらも効率は決してよくはないだろう。しかしできるできないの話で言えばできる。つまり.mjtさんが論じているのは究極的には人間とコンピュータのプロトコル（つまりUIだ）であって、それを実現するためのAPIやファイルシステムやカーネルはどうにでもできるのだ。つまりこれは独立した問題であって、いっしょに論じるべきではないと思う。
• もうすこし踏み込んで言えば、.mjtさんは「コンピュータに努力をさせて」人間に近づかせるべきだと考えている。そのほうが生産性が上がると考えている。そしてそれを効率的に実現できるように全ての下位のシステムは再設計されるべきだと信じている。たしかにそれは一つの見識だし僕もそういう設計方針のOSが絶対にあるべきだと思う。
• でも、OSASKはそういう方針じゃない。むしろ正反対だ。僕は（ある程度は）「人間に努力をさせて」コンピュータに近づかせるべきだと思う。たとえば僕は本気で人類は10進数を捨てて16進数に切り替えるべきだと信じている。.mjtさんの考えではこれはありえないと思う。人間が10進数に慣れているのだから、コンピュータが歩み寄って10進数を使えばいい、となるだろう。
• 僕は(1)で効率のよい状態がほしいと書いたけれど、そのためにOSだけを、ソフトウェアだけを作り直せばそれで終わりだとは思っていない。先の進数の例のように、人間性などに影響のないことであれば、それらはすべてコンピュータ寄りの常識に自分自身を再プログラミングしたいとまで思っている。だから（合理性とは程遠い）現在の人間の感性を中心にOSを設計するつもりはない。まずコンピュータにとって何が一番容易であるのかを突き止めて、その上で人間にどうしても受け入れがたいところと人間にも容易に受け入れられる部分の2つに分類し、コンピュータに妥協を迫った場合のオーバーヘッドを見積もり、その上でどうするかを考えたい。
• 結局.mjtさんが追い求めているのは現在の人間にとって最適なOSであり、僕が追い求めているのはニュータイプにとって最適なOSである。そして僕はオールドタイプの人間の癖にニュータイプ用OSを使い続けることで、いつか準ニュータイプに・・・（笑）。
• つぎにアプリのサイズについて。「システムとして出荷されたときのバイナリサイズよりも、実行時に占めるメモリサイズのほうが多分重要」というのは僕も基本的には賛成だ。だから「ぐいぐい01」は無圧縮の場合でも他のOS用アプリよりも小さい。でも、ファイルキャッシュやディスクスペースの節約を考えたら、圧縮して小さくなるのなら圧縮しておくほうが有利なので、さらに圧縮を適用しているに過ぎない。
• データのサイズのほうがサイズとしては（ストレージ使用量もメモリ使用量も）影響が大きい、むしろ圧倒的だ、という点についても基本的には同感だ。でもじゃあ、データファイルをこれ以上小さくできるのか？僕にはアイデアがない。tekで出し尽くした。個々のファイルフォーマットまで再検討すれば改善の余地はあるだろうが、それをやるとして、まず最初に目を付けたのが実行ファイルフォーマットだったというだけのことだ。これはデータじゃないけれど、でも削る余地がたくさんありそうだったのもまた事実だったので。
• そして最後の段落の「一つ一つのプログラムを～」というのがあるが、僕はむしろプログラムは部品化して組み合わせて使用していくという方向性を追求したい。これでも「必要な部分だけをロードする」は結果的に実現できる。これをやるには、ある複数の機能をもつアプリケーションを複数に分割したとして、個々に巨大なヘッダが含まれるのならロード時間の無駄だし、合計サイズもやたらと増える。これでは分割に及び腰になる。しかし「ぐいぐい01」のようなものならそういうことはない。・・・これはあくまでも内部実装の話であって、ユーザがいつもパイプなどでこれらの部品をつないでいかなければいけないということではない。makeやシェルスクリプトなどで隠蔽されていていいのである。
• それにプログラムの数を減らすことと個々のプログラムを小さくすることはトレードオフじゃないので、どちらがより効率的かを論じるべきではないと思う。つまりプログラミング不要なケースを増やしてプログラムの数を減らすことはできるし、その一方でAPIやファイルフォーマットを追及して、個々のプログラムをより小さくすることもできる。どちらを先に着手するかという話はありうるけど、ここは開発の優先順位の話題じゃない。
• 最後に「APIコールの効率性とシステムの効率性を関連付けられない」について。これは結局は簡単な話だ。たとえばある出力を得るために、100ステップの工程が必要なシステムと10ステップの工程だけでできるシステムがあれば、どちらが効率的だろうか。これを論じるには、それぞれのステップの処理時間をつぶさに比較しなければ正確なことは言えない。しかし第一近似として、10ステップのほうが効率はよさそうだということはできる。そして僕が言っているのも結局はその程度だ。それ以上の精度を出すにはベンチマークなどをやるしかない。・・・近似を否定して関連性は全くないとして片付けてしまうことはもちろんできるが、そこから何か得られるだろうか。僕はそれよりも近似は近似として受け入れて、役に立ちそうな場面では利用し、むしろそれが不十分であればその近似精度を上げる方法を考えたい。

こめんと欄