MINIXの30年の歴史から学んだこと (原題: Lessons learned from 30 years of Minix)

(本文書はAndrew S. Tanenbaum教授の許可をいただいて島慶一が翻訳しました。)

Linuxのことはみなさんよくご存知だと思いますが、その直接の祖先であるMINIXも齢三十を迎え、古参のソフトウェアとしてはまだまだ元気にやっています。MINIXの生い立ち、またMINIXやLinuxの始まりの物語はあまり知られておらず、だからこそMINIXの開発から多少なりとも学ぶべきことがあるのではないかと思うのです。これからお話しすることには、オペレーティングシステム特有の話があり、またソフトウェア開発の話もあり、それ以外 (例えばプロジェクト管理など) の話もあります。MINIXもLinuxも、何もないところから生まれたわけではありません。どちらにも誕生までのちょっとした歴史があり、筆を進める前に少しばかり昔話をしようと思います。

1960年、後に私の学び舎となるマサチューセッツ工科大学 (Massachusetts Institute of Technology、MIT) には、ひと部屋をまるごと占有するほど巨大な科学研究用の真空管コンピュータIBM 709がありました。最新のApple iPadはこれよりも70,000倍高速で、7,300倍のメモリを搭載しているわけですが、IBM 709が登場した時には、これが間違いなく世界で最も高性能なコンピュータでした。ユーザは、一般的にはFORTRAN言語で80桁のパンチカードにプログラムを書き、そのプログラムをコンピュータに読み込ませてくれる操作担当者のところに持っていったものです。プログラムの実行結果は数時間後に132桁の折り畳んだ用紙に出力されました。FORTRANプログラムのコンマの位置をたった一箇所間違っただけもコンパイルエラーが発生し、貴重な数時間を失うこともありました。

ユーザにより良いサービスを提供するため、MITは互換タイムシェアリングシステム (Compatible Time-Sharing System、CTSS) と呼ばれる仕組みを開発しました。CTSSはユーザに対話的な操作を提供し、コンピュータとのやりとりにかかる時間を数時間から数秒に短縮したのです。さらに、ユーザに使われていない時間は、古き良きバッチ処理にあてることができました。1964年、MIT、ベル研究所 (Bell Labs)、GE (General Electric、当時はコンピュータを製造していた) が連携して、何百人にも及ぶボストン地域のすべてのユーザに対応できる次世代システムの設計に取り掛かりました。これはクラウドコンピューティングVer.0.0と呼んでもいいかもしれません。そのシステムはMULTiplexed Information and Computing Service、略してMULTICSと呼ばれました。この話を始めると長くなるので結論だけ言いますが、MULTICSは問題児でした。最初のバージョンはGE 645に搭載されていた288kBのメモリをすべて使っても収まりきりませんでした。最終的には、システムのPL/1コンパイラが改善されたことでなんとか動き出したのですが、ベル研究所はしばらくするとMULTICSに興味を失い、引き上げてしまいます。ただひとり、MULTICSの縮小版を作って安価なコンピュータでも実行できるようにしたいと言う熱い願望を持った、当時MULTICSプロジェクトのプログラマであったKen Thompsonだけが残されました。MULTICSは1973年に製品として発表され、最後の一台が2000年10月30日に停止するまでの実に27年もの間、多くのシステムが世界中で動き続けました。

一方、ベル研究所では、Thompsonが捨て去られていたDigital Equipment社のPDP-7ミニコンピュータを拾い上げ、機能削減版のMULTICSをPDP-7の機械語で書き直していました。そのシステムは同時にはひとりのユーザしか処理できなかったので、Thompsonの同僚だったBrian Kernighanは皮肉を込めてUNIplexed Information and Computing Service、UNICSと言うあだ名をつけました。去勢されたMULTICSと言う意味での宦官 (EUNUCHES、発音がUNICSと似ている) と言う単語からの語呂合わせだったにもかかわらず、UNICSと言う名前は生き残り、後にUNIXと呼ばれるようになりました。UNIXは今ではUnixとも表記されます。なぜならもうUNIXは何かの略語でもなんでもないのですから。

1972年、Thompsonはベル研究所の同僚であり、C言語の設計とCコンパイラの作者でもあるDennis Ritchieとチームを組み、UNIXをPDP-11ミニコンピュータ上でC言語を使って書き直しました。UNIXは研究所内で何度も改版され、1975年にUNIX V6としてベル研究所から300ドルで大学にライセンス提供されました。PDP-11は当時大変な人気だったため、UNIXは瞬く間に世界に広がっていきます。

1977年、オーストラリアはシドニーのニューサウスウェールズ大学 (University of New South Wales) に在籍していたJohn LionsがV6のソースコードの解説本を出版します。それは一行一行に渡って何をしているのかを説明するもので、さしずめ聖書の一行一行に説明をつけたものの技術書版と言えるでしょう。世界中の数百に及ぶ大学がLionsの本を使ってUNIX V6の講義を始めたのです。

ベル研究所の親会社であるAT&Tの弁護士はこの出来事に愕然とします。数千人もの学生がAT&Tの製品の全てを大学で学んでいるのですから。これは止めさせなければならないと言う訳で、改訂版のV7 (1979年) には、製品に関する本を書くことや、学生向けの教材として使うことを明示的に禁止したライセンスが付属することになりました。オペレーティングシステムの講義は、理論だけを教えるものか、あるいはおもちゃのようなシミュレータを使ったものに逆戻りし、世界中の教授たちが落胆します。初期のUNIXの歴史は1994年に出版されたPeter Salusの本で解説されています。

MINIXの誕生

この問題は1984年に私が仕事の合間の時間を使ってV7を書きなおそうと決心するまで続きます。私はオランダのアムステルダム自由大学 (Vrije Universiteit、VU) に勤務しており、学生が授業で使うため、あるいは彼らが自分で学習するためのUNIX互換のオペレーティングシステムを提供したいと考えていました。名前はMIni-uNIX、MINIX、対象システムは当時最新のIBM PCです。IBM PCは1,565ドルから買うことができた安価なコンピュータで、学生にも手が届く値段でした。初期のPCはハードディスクを搭載していなかったので、MINIXはV7互換でありながら、256kBのメモリと360kBの5.25インチフロッピーディスクドライブ1台だけしか持たないIBM PCでも実行できるように設計しました。これはPDP-11用のV7と比較するととてつもなく小さなものです。ただ、システムはこの構成で動いたとしても (実際動きましたが)、システム全体をPC上でコンパイル、構築し直すにはより高機能な構成が必要だと言うことは初期の段階から分かっていました。具体的にはPCの最大搭載メモリ640kBと360kBの5.25インチフロッピーディスクドライブ2台です。

最初、私はウォータールー大学 (University of Waterloo) の卒業生たちによって書かれた、Mark Williams Coherentと言うV7互換オペレーティングシステムを動作させた自宅のIBM PC上で開発していました。このソースコードは公開されていませんでした。最初はCコンパイラすら持っていなかったので、Coherentを使う必要があったのです。後に、我々のプログラマだったCeriel Jacobsが、私の研究の一部としてVUで開発されたAmsterdam Compiker Kitを基にしたCコンパイラを移植し、システムは自己完結となりました。MINIXをコンパイルするためにMINIXを使う必要があったので、私は発見されるいかなる不具合や欠点にも極限まで敏感になっていました。すべての開発者は自分が作ったシステムをできる限り早い時期から使い始めるべきです。そうすることでユーザが経験しそうなことを実際に体験することができるからです。

マイクロカーネルはとても小さくできました。スケジューラ、低レベルプロセス管理、プロセス間通信、そしてデバイスドライバのみがカーネルに含まれていました。デバイスドライバはカーネルの実行プログラムに組み込まれてはいましたが、実際には通常のプロセスと同じように独立してスケジューリングされました。これはひとつの妥協でした。デバイスドライバを動作させるためにアドレス空間全体の切り替えを行うのは、IBM PCに搭載されていた4.77MHzの8088プロセッサには少々荷が重いと感じたからです。マイクロカーネルは独立した単一の実行プログラムとして構築されます。その他のオペレーティングシステムの機能、ファイルシステムやメモリ管理などは、別のプログラムとして構築され、別プロセスとして動作しました。8088プロセッサにはメモリ管理機構 (Memory Management Unit、MMU) がなかったので、近道をして全てをひとつの実行ファイルにしてしまうこともできましたが、そうはしないことにしました。将来、MMUを搭載したCPUでも動作するように設計したかったからです。

最初のコードが動きだすところに漕ぎ着けるまでに、仕事が終わった後と週末の時間だけを使っておよそ2年かかりました。システムの基本的な部分が動き出すと、今度は1時間ほどで、何の理由も決まったパターンもなくクラッシュし始めました。素のコンピュータ上でオペレーティングシステムをデバッグするのはほとんど不可能で、危うくプロジェクトを諦めてしまうところでした。

私は最後の努力を試みました。クラッシュした時に適切なメモリダンプとスタックトレースを入手するために、8088プロセッサのシミュレータを書いて、その上でMINIXを実行することにしたのです。光栄なことに、と言っていいと思いますが、MINIXはシミュレータ上では何日も、何週間さえも完璧に動きました。一度たりともクラッシュしなかったのです。完全に面食らいました。私は研究室の学生だったRobbert van Renesseに、MINIXがシミュレータでは動くのに実際のハードウェアでは動かないと言う話をしてみたところ、彼は8088プロセッサは温度が高くなると割り込み15を発生させると聞いたことがある、と言うではありませんか。そんな情報は8088プロセッサの仕様書のどこにも書かれていないと反論しましたが、彼は絶対にどこかで聞いた、と言い張ります。そこで私は割り込み15を捉えるコードを追加してみました。1時間もしないうちに画面に次のメッセージが表示されました「やぁ。僕は割り込み15。君がこのメッセージを見ることは決してないだろう」。私はすぐに割り込み15を処理するために必要な修正を加えました。斯くしてMINIXは完全動作するようになり、リリース可能となったのです。

教訓: やみくもに仕様書を信用しないこと。間違っているかもしれないから。

30年経った今、Van Renesseの思いつきの助言の結果には目を見張るものがあります。もし彼が割り込み15の話をしなかったら、私はおそらく望みを失って最後には諦めていたと思います。MINIXが存在しなければ、Linuxが誕生したとは考えられません。なぜならLinus TorvaldsはMINIXのソースコードを隅々まで調べることでオペレーティングシステムを学び、Linuxを作るための土台としてMINIXを使ったのですから。LinuxがなければAndroidもなかったことでしょう。なぜならAndroidはLinuxの上に構築されているのですから。そしてAndroidがなければ、AppleとSamsungの株価の状況も、今とは違ったものになっていたかもしれません。

教訓: 学生の言葉に耳を傾けよう。彼らはあなたより物知りかもしれない。

基本的なユーティリティのほとんどは私が書きました。MINIX 1.1はarからwcに至るまで、60のユーティリティを提供していました。およそどれも4kB程度の大きさです。今では、ブートローダですらその100倍のサイズになっていますが。MINIXのすべては、バイナリとソースコードを含めても、8枚の360kBのフロッピーディスクに収まりました。そのうち4枚が、ブートディスク、ルートファイルシステム、/usr、そして/userです (図1)。残りの4枚にはオペレーティングシステムと60個のユーティリティのソースコードが入っていました。コンパイラのソースコードだけが、サイズが大きすぎたため含まれていませんでした。

教訓: Nathan Myhrvoldの法則は正しい。ソフトウェアはガスのようなもので、入れ物がいっぱいになるまで膨らんでいく。

開発者たちがこの「法則」を打ち破る事は可能かもしれませんが、それには大変な努力が必要になるでしょう。基本は「もっといっぱい」です。

コードの配布方法は大きな課題でした。当時 (1987年)、ほとんど誰もインターネットに接続する手段を持っていませんでした (少数の大学では、UUCP経由でのUSENETニュースグループや電子メールを利用できましたが)。私は、Lionsが以前したように、コードを解説する本を書き、本の出版社であるPrentice Hallに、すべてのソースコードを本のおまけとして付属させることでシステムを配布しようと決心しました。交渉の結果、Prentice Hallは8枚の5.25インチのフロッピーディスクと500ページの解説書をいい感じに箱詰めしたものを69ドルで販売してくれることになります。この価格はほぼ全て製造原価でした。Prentice Hallはソフトウェアの中身について全く理解してはいませんでしたが、より多く本を売るための手段としてソフトウェアを売る必要があることは理解していました。後に、高密度な1.44MBの3.5インチフロッピーディスクが使えるようになると、それらを利用したものに刷新しました。

教訓: あなたの製品がどれほど魅力的であっても、それを販売したり、配布したりする方法が必要だ。

出版から数日後、USENETのcomp.os.minixニュースグループが設立され、1か月もしないうちに40,000人もの読者を獲得します。当時USENETにアクセスできた人がいかに少なかったかを考えれば巨大な人数です。MINIXは瞬く間に人気コンテンツになりました。

ほどなく、シリコンバレーの今は存在しないComputer Literacy書店の共同設立者であるDan Doernbergから、シリコンバレーに行くことがあればMINIXについて講演して欲しいとのメールをもらいました。結局私は数週間後にベイエリアで開催される会議に出席することになり、依頼を受けることになります。私は彼が彼の書店にサイン会のためのテーブルと椅子程度を準備してくれているものだと思っていました。全く知らなかったのですが、彼はサンタクララの展示場にある公会堂を借り切っていて、ほぼ満員になるくらい聴衆を集めてくれていたのです。講演が終わった後も、深夜になるまで質問が続きました。

その後、私はあれやこれやと機能の追加を依頼する (と言うよりも、要求する) メールを何百通も受け取り始めました。要求のいくつか (すべてではありません) は却下しました。システムが大きくなりすぎて、学生には手がだせないような高価なハードウェアが必要になることを心配してのことでした。また、多くの人が、私自身ですら、GNU/HurdやBerkeley Software Distribution (BSD) が、完全オープンソースの製品システムと言う隙間産業を引き継ぐものだと思っていたからです。私は教育分野に注力し続けました。

ソフトウェアを提供してくれる人も現れ始め、中にはとても有用なものもありました。システムのデバッグを補助してくれる大変便利なテストスイートを書いてくれたJan-Mark Wamsは、そういった貢献者たちのひとりです。彼はまた、当時のどのプログラムよりも優れた新しい圧縮プログラムも作ってくれました。おかげで配布に使うフロッピーティスクを2枚減らすことができました。これは後にオンラインで配布するようになっても重要でした。みんなが超高速56kbpsのモデムを持っていたわけではありませんから。

1985年にIntelがプロテクトモードを搭載した32ビットアーキテクチャの386プロセッサを発表しました。たくさんの人々、特にオーストラリアのBruce Evansの助力のおかげで、私は32ビットプロテクトモード版のMINIXを公開することができました。初めから将来のハードウェアのことを常に検討していたおかげで、8088プロセッサに動作モードはひとつしかなかったにもかかわらず、「カーネルモード」で動作すべきコードと、独立した「ユーザモード」で動作すべきプロセスのコードは明確に区別できていました。このことは、386プロセッサでこれらのモードが出現した時に大きな助けになりました。また、元のコードは仮想アドレスと実アドレスを明確に区別していたので (これは8088プロセッサではあまり問題ではありませんが、386プロセッサでは「大いに」問題でした)、移植はさらに容易なものでした。ちょうどこの頃、VUのKees BotとPhilip Homburgのふたりが仮想メモリを搭載した素晴らしい32ビット版を実装していましたが、私はより元の設計に準じたEvansの設計を採用しました。

教訓: 将来現れるかもしれないハードウェアにも適応できるような設計を心がけよ。

1991年までに、MINIX 1.5はApple Macintosh、Amiga、Atari、Sun SPARCStation、その他多くのプラットフォームに移植されました (図2)。

教訓: ハードウェア特有の特殊な機能に頼らなければ、新しいプラットフォームへの移植がより簡単になる。

システムの開発が進むにつれ、思いがけないところで問題が発生しました。特に頭を悩ませたのが、デバッグができないネットワークカードドライバでした。最終的には、誰かがそのカードが仕様書通りに動いていなかったと言うことを発見してくれました。

教訓: ソフトウェアと同じように、ハードウェアにもバグがある。

ハードウェアの「特徴」は、時としてハードウェアのバグと見做されることがあります。当時のイタリア大手コンピュータ製造業者Olivettiが販売していたPC互換機に移植されたMINIXが、その原因に気がつくまではどうにも説明のできない理由で問題を起こしていました。Olivettiのキーボードのキーのいくつかが、純粋なIBMのキーボードが返すスキャンコードとは異なるコードを返していたのです。この問題をきっかけに、私は多くの国がその国独自の標準的なキーボードを使っていることに気がつきました。そこで私はMINIXをインストールするときに複数のキーボードを選択できるように変更しました。この変更は、イタリア語、フランス語、ドイツ語、またその他の国内向けキーボードを使う人々にとって有用です。アメリカ以外の国の人々により使いやすいMINIXを提供できる方法を発見したことで、私のOlivettiへの苛立ちは和らぎました。同様に、これ以降も、最初はバグだと思われていたことが、システムをより汎用的なものへ改善する動機となったことがいくつもありました。

Linus Torvalds、PCを買う

1991年1月5日、ヘルシンキ大学に在籍するフィンランド人の学生、まだ名前が知られる前のLinus Torvaldsが重大な決断をします。彼は、主にMINIXを動かして勉強するために、高速 (33MHz)、大容量 (4MBのメモリと40MBのハードディスク) PCを購入したのです。1991年3月29日にはUSENETニュースグループのcomp.os.minixに最初の投稿をしています。

「やぁみんな。minixを手に入れてから1週間、386-minixにアップグレードして (こいつはいい)、minix用gccもばっちりダウンロードした…」

彼の二回目のcomp.os.minixへの投稿は1991年4月1日で、誰かの簡単な質問に対する反応でした。

「RTFSC (Read the F***ing Source Code :-) (あの***しいソースコード読めよ :-))。しっかり解説してあるし、解決方法は明らか…」

この投稿から、Torvaldsは10日ほどで、少なくとも彼ほどには勉強していない人に対して若干横柄な態度を取れるくらいには、MINIXのソースコードを深く理解していたことがわかります。もちろん、当時のMINIXの目標は学生が簡単に学習できるようにすることでしたから、Torvaldsの場合においては、多少乱暴ですが目論見通りだったと言えるでしょう。

「minix使いのみんな、僕は今386 (486) AT互換機用の (無料の) オペレーティングシステムを作ってるんだ (単なる趣味。gnuみたいに本格的にするつもりはないけどね)。4月から始めてたんだけど、準備ができたよ。minixの好きなところや嫌いなところを聞かせてくれないかな。僕のOSは ((使い勝手上の理由で) ファイルシステムの物理配置とか、いろんな部分が) minixに似てるから。」

次の年も、TorvaldsはMINIXを学び、また彼の新しいシステムを開発するために使い続けました。これが最初のLinuxカーネルになります。LinuxカーネルがMINIXのファイルシステムとソースコードの配置を踏襲している点などが、LinuxとMINIXのつながりの痕跡として残り、後のソフトウェア考古学者の目にとまるところとなりました。

1992年1月29日、私はマイクロカーネル設計は性能の点以外ではモノリシックカーネル設計よりも優れている、と言う内容をcomp.os.minixに書きました。この投稿は、24年経った今に至る炎上を引き起こし、未だに世界中の多くの学生がこの「議論」に対する彼らの主張を私に書き寄こしたり、語りかけてきたりします。

教訓: インターネットは象みたいなものだ。彼らは決して忘れない。 (訳注)

つまり、インターネットで何かを公開するときには注意が必要だと言うことです。何10年も経ってからあなたの前に化けて出てくるかもしれません。

私が当初想定していたよりも、性能を重要視する人がいると言うこともわかってきました。MicrosoftのWindows NTはマイクロカーネルとして設計されていましたが、後に性能が問題になるとハイブリッド設計に変更されました。NTに限らず、Windows 2000、XP、7、8、そして10でも同様ですが、 (マザーボードの差を吸収するために) 最下層にハードウェア抽象化層が作られています。その上が、割り込み、スレッドスケジューリング、低レベルのプロセス間通信、スレッド同期を処理するマイクロカーネルです。マイクロカーネルの上がWindowsの実体であり、プロセス管理、メモリ管理、I/O管理、セキュリティなどの独立した部品の集合体が一体となってオペレーティングシステムの核を構成しています。これらの部品が、MINIXがそうしていたのと同様に、きちんと定義された手順に従って相互に通信しています。異なるのは、MINIXではこれらの部品がユーザプロセスだった点です。NT (およびその子孫) では、コンテキストスイッチの数を減らすと言う性能上の理由から、これら全てがカーネルモードで動作する一種のハイブリッド構成となっていました。よって、ソフトウェア工学的な視点でみればNTはマイクロカーネル設計なのですが、信頼性の面ではモノリシック設計でした。どこかの部品のたったひとつのバグがシステム全体のクラッシュを招きかねないと言うことです。AppleのOS Xも似たようなハイブリッド設計になっており、最下層にMach 3.0マイクロカーネルが配置してあり、その上にFreeBSDに由来する上位層 (Darwin) が載っています。FreeBSDはカリフォルニア大学バークレー校 (University of California at Berkeley) で開発されたBSDシステムの子孫にあたります。

なお、信頼性が性能よりも重視される組み込みコンピュータの世界では、マイクロカーネルが支配的であると言うことを書き添えておきたいと思います。UNIXに似た商用リアルタイムオペレーティングシステムのQNXは、自動車、ファクトリーオートメーション、電力設備、医療機器などで広く採用されています。L4マイクロカーネルは世界中の10億を超える携帯電話の無線チップや、iPhone6など最近のiOSデバイスのセキュリティプロセッサのOSとして採用されています。L4はとても小さいため、およそ9,000行からなるC言語で書かれたソースコードは、その仕様書に対して数学的に正しいことが証明されています。何百万行にも上るモノリシックシステムでは考えられないことです。それにもかかわらず、マイクロカーネルは歴史的な理由、あるいは少々性能的に劣っていると言う理由で未だに論争の種となっています。

1992年、私は、RISCマシンが将来は多勢を占めるのだから、Linuxを386アーキテクチャに強固に結びつけてしまう設計は望ましくない、と言う意見をcomp.os.minixニュースグループに投稿しました。500億以上もの (RISC) ARMチップが出荷されている現状を鑑みるに、この指摘はある程度正しかったと言えるでしょう。ほとんどのスマートフォンやタブレットがARM CPUを、これにはQualcommのSnapdragon、AppleのA8、SamsungのExynosなどの亜種も含みますが、搭載しています。さらには64ビットのARMサーバやノートPCも現れ始めました。Linuxは結局はARMに移植されましたが、もし最初からx86アーキテクチャに依存しない形になっていればもっと楽に進めることができたはずです。

教訓: 今主流のハードウェアが今後もそうだと思わないこと。

同様に、Linuxがgccコンパイラに強く依存していたため、clang/LLVMなどの新しい(そしておそらくは、より良い) コンパイラを使うためには大きなコード修正を余儀なくされました。

教訓: (例えばANSI Cなどの) 標準があるときはそれに従おう。

Linuxが走り始めた1992年、ある重要な出来事がありました。AT&TがBSDI (BSDソフトウェアの販売とサポートをするためにBerkeley UNIXの開発者たちが作った会社) とカリフォルニア大学 (University of California) を訴えたのです。AT&Tは、BSDがAT&Tのコードの一部を含んでおり、またBSDIの電話番号1-800-ITS-UNIXがAT&Tの知的財産権を侵害していると主張しました。1994年にこの事案の決着がつくまでの間、BSDは足枷をつけられた状態となり、致命的といえるほどの時間の猶予をLinux開発陣に与えることになりました。もし、AT&Tがもう少し思慮深く、BSDIを訴えるのではなく営業のための道具として買収していたら、Linuxがこれほどまでに成熟、安定し、巨大な市場を抱える競争相手になることはなかったかもしれません。

教訓: もしあなたが世界屈指の大企業を経営していて、これから進出しようとしているがそうよくは知らない分野に小さなスタートアップが現れた時には、スタートアップのオーナーにいくら欲しいか聞いて、小切手を切ったほうがいい。

1997年、UNIX V7互換よりもむしろPOSIX互換となったMINIX 2が、マサチューセッツ州ハンプシャー大学 (Hampshire College) のAlbert Woodhull教授を新たに共著者として迎え入れた私の本Operating Systems Design and Implementationの第2版とともに発表されました。

2000年、ついに私はMINIX 2をBSDライセンスの下で公開することをPrentice Hallに納得させ、すべてを (ソースコードを含んだ形で) 無料でインターネットに公開しました。もともと大学向けには制限のない利用を許可していましたし、ほぼ出版社の製造コストだけで販売していたのですから、もっと早くこうするべきでした。

教訓: 一旦採用した戦略も、時とともに見直すべきである。

研究プロジェクトとしてのMINIX

MINIX 2はその後も数年に渡りゆっくりと開発が続けられていましたが、私が2004年にオランダ科学研究機構 (Netherlands Organization for Scientific Research) から資金の提供を受けた時に、教育目的の趣味的プロジェクトから高信頼システムを構築するための研究プロジェクトへと大きく舵を切りました。2004年まで私は外部からの資金は一切受け取っていませんでした。まもなく、私はアムステルダムのオランダ王立芸術科学アカデミー (Royal Netherlands Academy of Arts and Sciences) で教授の職に就きます。同時に300万ドルに上る予算がMINIXを基盤とした高信頼性オペレーティングシステムの研究に投入されました。

教訓: たとえ世間の本流でなかったとしても、本当に重要なことに取り組んでいれば予算は後から付いてくる。

もちろん、MINIXがマイクロカーネルを研究する唯一のプロジェクトだった訳ではありません。1970年まで遡れば、初期のシステムとしてAmoeba、Chorus、L3、L4、Mach、RC 4000 Nucleus、Vなどが挙げられます。マルチサーバ構成の耐障害性の高いPOSIX互換システムをマイクロカーネル上に構築すると言うところが、MINIX研究が斬新だった点でした。

2004年、私は学生とプログラマとともにMINIX 3の開発を始めます。最初の目標はデバイスドライバを完全にマイクロカーネルの外に出すことでした。MINIX 1とMINIX 2では、デバイスドライバは独立したプロセスとして処理され、スケジューリングされてはいたものの、マイクロカーネルの (仮想) アドレス空間に配置されていました。私の学生であったJorrit Herderの修士論文は、各ドライバをユーザプロセスとして作り直すと言う内容でした。この変更でMINIXはより高信頼で堅牢になりました。彼はその後、私の元でのVU博士課程中に、壊れたドライバを、システムを実行したまま何の副作用も発生させずにその場で差し替えることが可能であることを示しました。コピーがメモリ上に保持されているので、壊れたディスクドライバですら差し替え可能でした。それ以外のドライバはいつでもディスクから読み出すことができます。これは自己修復システムのための最初の一歩でした。他のどのシステムにもできないことをMINIXができるようになったこと、すなわち、再起動はもちろん、動作中のアプリケーションに認知されることすらなしに、鍵となるオペレーティングシステムの故障した部品を差し替えることができると言うことは、私たちが何か素晴らしいことを成し遂げようとしているのだと言う自信を与えてくれました。

教訓: 何かの形で早めに成功を収めるように心がけよう。成功は私たちの士気を高めてくれる。

この変更は、最小権力の原則 (Principle of Least Authority)、あるいは最小権限の原則 (Principle of Least Privilege)とも呼ばれる概念をより洗練された方法で実装可能にしました。たとえデバイスドライバが自分のデバイスを操作する場合であったとしても、マイクロカーネルにお伺いを立てなければならないと言うことです。ドライバが対象デバイスを操作する権限を持っているかどうかをマイクロカーネルが確認することができるため、劇的に堅牢性が向上します。WindowsやLinuxのようなモノリシックなシステムでは、出来の悪い、あるいは正しく動作していないオーディオドライバがディスクを消去してしまうほどの権限を持つことができます。MINIXではマイクロカーネルがそういった操作を防ぐことができます。もしI/Oメモリ管理ユニットがあれば、同じ効果を実現するためのマイクロカーネルによる調停は必要ないでしょう。

さらに、ソフトウェアコンポーネントはマイクロカーネルが許可した場合に限って他のコンポーネントと通信することができます。誰と誰が通信できるかは、マイクロカーネル内で管理されるテーブルとビットマップで制御されます。オペレーティングシステムのコンポーネントにより厳密な制限を設ける新しい設計 (と、その他の改善を加えたもの) はMINIX 3と呼ばれ、私とWoodhullが書いたOperating Systems Designs and Implementation第3版と同時に発表されました。

教訓: すべてのデバイスドライバは特別な権限を持たない、ユーザ空間のプロセスとして動作すべきである。

Microsoftはこのことを明確に理解していましたし、今も理解しています。これを実現するため、Windows XPとその後継システムではユーザモードドライバの枠組みが導入され、デバイスドライバの作者にユーザ空間のプロセスで動作するデバイスドライバを書くことを推奨しています。まさにMINIXがそうであるように。

2005年、私はACMのSymposium on Operating System Principles (http://www.sosp.org) に基調講演の講演者として招待されました。オペレーティングシステム研究の最高峰です。会議は2005年の10月にイギリスはブライトン市のGrand Hotelで開催されました。私はここで、会場に集まったオペレーティングシステムの専門家たちに、MINIX 3の公式なお披露目をしようと決めていました。講演の途中で私は礼服を脱ぎ、身につけていたMINIX 3 Tシャツを露わにしました。MINIXのウェブサイトでは、この日までにMINIX 3のダウンロードが可能な状態に設定してありました。言うまでもなく、私はウェブサーバがダウンロードの負荷に耐えられるかどうか確認するため、会議の間ずっとオンラインでいたいと思っていました。私は会議の特別招待者だったらしく、私に与えられた部屋は、女王陛下がブライトンに来ることがあったならばきっと滞在したであろうロイヤルスイートでした。部屋はとても広く、窓からは壮大な海を見下ろすことができました。ただ残念ながら、その部屋はホテルで唯一インターネット接続が提供されていない部屋だったのです。確かに、女王陛下はインターネットのヘビーユーザではないでしょうからね。さらに悪いことに、ホテルにはWi-Fi接続もありませんでした。幸い、会議運営者のひとりが私をかわいそうに思ったのか部屋を交換してくれることになり、標準的ですが、とっても重要なイーサネットポートのある部屋を確保できました。

なんだかよさそうなもの (素敵なホテルの部屋とか) が目の前に現れても気を散らさないことです。実際には邪魔になるだけですから。

2005年頃にはMINIX 3はさらに本格的なシステムになっていました。ところが、多くの人々にとってMINIXはOperating Systems Design and Implementationで学ぶ、授業の教材であったため、MINIXがもはやおもちゃではないと言うことを納得させるのは大変困難でした。皮肉なことに、とても広く知られたシステムであるにも関わらず、その生い立ちのせいでなかなかまともに取り扱ってもらえなかったのです。この点において、Microsoftはより賢明でした。初期のWindows、Windows 95やWindows 98は単にMS-DOSにグラフィックによるシェルを被せただけのものでした。しかし、もし彼らがそのシステムを「グラフィカルMS-DOS」なんて言う名前で売り出していたら、実際彼らが選択したように「Windows」と名前を変えた場合ほどには普及しなかったかもしれません。

教訓: もしあなたの製品の第3版が第2版から大幅に改訂されているなら、全く別の名前を付けなさい。

2008年、MINIXプロジェクトはもうひとつの幸運に恵まれました。当時、欧州連合 (European Union、EU) は数年に渡って製造責任に関する法律をソフトウェアにも適用できないか検討していました。もし1千万のタイヤのうちのひとつが破裂し、誰かの命を奪ってしまった場合、製造業者は単に「タイヤの破裂事故が起きました」とだけ言って事態を収拾するわけにはいかないでしょう。しかしソフトウェアではこの論理がまかり通るのです。国あるいは司法は技術的に不可能な法律を制定することはできません。そこで、欧州連合によって設立された欧州研究評議会 (European Research Council) は、欧州研究評議会先進予算 (European Research Council Advanced Grant) からおよそ350万ドルを捻出し、私がMINIXを基にして高度に信頼できる、自己修復可能なオペレーティングシステムを作ることができるかどうか見てみることにしたのです。

私はこの好機に大変感謝したのですが、計り知れないほどの幸運は大きな問題も生みました。私は「MINIX 3 - 製品版」を開発するために4人の専門プログラマを雇うことができました。加えて、研究の可能性の限界に挑むため、6名の博士学生とさらに数名の博士号を持つ研究者を雇う資金もありました。博士学生はすぐにMINIX 3のソースコードをコピーし、彼らの研究に活用するために大きく変更を加え始めました。一方、プログラマはコードを洗練し、「製品化」するために大忙しでした。その結果、2~3年経つ頃にはもうコードをひとつに統合することができなくなっていました。gitやその他の洗練されたツールを使っていたにも関わらず、注意深く開発されたプロトタイプと学生が開発したものには非常に大きな隔たりがあり、学生の変更を反映することができなかったのです。これらのバージョンにはまったく互換性がなくなっていました。例えば、ふたりの開発者がまったく異なるアルゴリズムで完全にスケジューラを書き直してしまったら、後でそれらを自動的に統合することなど不可能です。

また、私は研究の成果を製品に組み込んでいきたいと望んでいたのですが、プログラマたちはこの考えに猛反対しました。彼らは彼らが書いたコードを変更することに驚くほど慎重であり、十分に検証された製品に学生品質の、ほとんど検証もされていないコードを取り込むことに (控えめに言っても) それほど熱心ではなかったのです。研究の成果ひとつを製品に組み込むだけでも、私たちのグループは大変な努力を費やす必要がありました。一方で、私たちはたくさんの論文を世に出すことができました。例えばAppuswamyらの論文、Giuffridaらの論文その1、Giuffridaらの論文その2、Hrubyらの論文などです。

教訓: 博士課程の研究とソフトウェア製品の開発を同時に成し遂げるのは大変困難である。

時に、研究者とプログラマが同じ問題に遭遇することもありました。そのひとつは同期通信の使い方に関係するものでした。同期通信は開発初期から存在している単純な機能です。と同時に、信頼性を高めると言う目標と競合するものでもあります。もし、クライアントプロセスCがサーバプロセスSにメッセージを送信したのちにクラッシュあるいは応答を受け取ることのない無限ループに陥ってしまうと、サーバは応答を返すことができなくなり膠着してしまいます。この問題は同期通信につきものです。問題の解決のため、私たちは仮想終端や非同期通信など、本来の設計とはかけ離れた醜い実装を採用しなければなりませんでした。

教訓: アインシュタインは正しかった。物事はできる限り単純であるべきだ。ただし単純過ぎてはいけない。

アインシュタインの言葉の意味するところは、すべての人は物事を単純化する努力をし、目的を達成するために必要十分で余分な部分のないよう気をつけなければならない、と言うことでしょう。MINIXも当初から同じ設計理念を持っていました。残念ながら、最近の肥大化したソフトウェアには見られないものになっています。

2011年、ちょうど目指す製品の方向性が定まり始めたころに、私たちはふたつの重要な境地に達していました。ひとつ目は、システムを使ってもらうためにはアプリケーションが欠かせないと言うことを私たちが理解し始めたことです。そのため、私たちはヘッダ、ライブラリ、パッケージ管理ソフトウェアなど、多くのものをBSD (より正確に言えばNetBSD) から取り込みました。実際、私たちはNetBSDのユーザ環境をより堅牢なサブシステム上に構築し直したと言えるでしょう。このおかげで、6,000ものNetBSDのパッケージをいきなり使えるようになりました。

教訓: もしあなたが作った製品を誰かに使って欲しかったら、何かしら役に立つことができなければならない。

ふたつ目は、MINIX 3が堅牢性を備えた計算環境について研究するためのすばらしい基礎システムとして大学で広く使われていたにも関わらず、Windows、Linux、OS X、そして何種類ものBSDとのデスクトップ覇権戦争には勝ち目がないことを理解したことです。私たちはMINIX 3をARMプロセッサに移植し、堅牢性がより重要な条件となる組み込みシステムに注力を始めました。開発者は、彼らが新しいカメラ、テレビ、ビデオレコーダー、ルーター、その他いろいろな製品に組み込むためのオペレーティングシステムを選定するとき、1981年当時のシステムとの後方互換性を持ち、以前のシステムと変わらず高速にMS-DOSのゲームが動作することをぎゃーぎゃー求めてくる何百万ものユーザを相手にする必要はありません。ユーザは中で何が動いているかに興味はなく、製品そのものに興味があるからです。私たちはMINIX 3をARM Cortex-A8プロセッサが動作するBeagleBoneシリーズに移植しました (図3)。この組み込みボードは本質的に完全なPCであり、50ドルで手に入れることができます。このボードはしばしば組み込みシステムのプロトタイプ作成に活用されています。ハードウェアはすべてオープンソースとなっており、ボードがどうやって動いているのか簡単に理解できるようになっています。

回想: 今になったからこそ正しく理解できることもあります。まず、ハードウェアMMUによってお互いに保護されたユーザレベルのシステムコンポーネントを用いて小さなマイクロカーネルを作ると言う考えは、あるコンポーネントの問題が他のコンポーネントに影響しない設計を実現し、高度に堅牢、自己修復可能なシステムを作る上で今でも最良の方法だと言うことです。過去30年の間、MINIXのマイクロカーネルにほとんどコードが追加されなかったことは、おそらく驚くべきことです。実際、すべてのデバイスドライバとスケジューラの大部分を含むいくつかの主要なソフトウェアコンポーネントがマイクロカーネルから追い出されました。世界も (ゆっくりと) この方向に進んでいます (Windowsのユーザモードや組み込みシステムがその例です)。それにもかかわらず、オペレーティングシステムの多くの部分をユーザ空間プロセスとして実行することはなお非常に困難であり、この困難な考えを現実のものにするためには時間が必要です。例えばFORTRAN、Windows XP、メインフレーム、QWERTYキーボード、x86アーキテクチャ、ファックス、磁気クレジットカード、インターレースのNTSCカラーテレビ方式など、発明された当時は大きな意義があったかもしれませんが、今ではそれほどでもありません。しかしながら、これらの技術は静かに消え去っていくわけではないのです。Microsoftによれば、すでにサポートの終了したWindows XPが、2016年3月時点でまだ2億5千万台も稼働しているのですから。

更に言えば、今後コンピュータがどんどん強力になるにつれて、効率性はあまり重要ではなくなってくるでしょう。例えばAndroidはC言語よりもはるかに遅いJava言語で書かれていますが、誰も気にする様子はありません。

システム全体を通じて固定長のメッセージを使うことや、(mallocのような) 動的なメモリ割り当てやヒープ管理をカーネルから排除すると言う、1984年当時の私の初期設計に問題はなく、むしろ動的メモリ管理に関する問題 (メモリリークやバッファーオーバーラン) を回避できています。

MINIXでうまく動いたもう一つの仕組みはイベント駆動モデルです。各ドライバとサーバは次のようなループ構造を持っています。

{ get_request();
  process_request();
  send_reply();
}

この設計はプログラムの独立性を高め、テストとデバッグを容易にしてくれます。

一方で、MINIX 1のシンプルさはその活用場面を制限することもありました。カーネルレベルでのマルチスレッディング、デマンドページングなどは、256kBのメモリと一台のフロッピーディスクしか搭載されていなかった当時のIBM PCには現実的ではありませんでした。どこかの時点で、これらの機能 (とその複雑性) を追加することもできたと思いますが、(いくつかの回避策はあったものの) しませんでした。このツケは、いくつかのソフトウェアを移植する際に、これらの機能があった場合よりも移植が困難になると言う形で払い続けています。

研究予算は終了しましたが、MINIXプロジェクトは終わりません。他の多くのプロジェクトと同様、オープンソースプロジェクトに転換を始めています。様々な改良、中にはとても興味深い機能も開発されています。例えば、ほとんどすべてのオペレーティングシステムのドライバ、ファイルシステム、メモリ管理、プロセス管理などを、(おそらくデータ構造も異なる) 新メジャーバージョンに動作を止めることなく更新できる機能などです(Giuffrida2013-1、Giuffrida2013-2)。更新時に一瞬だけシステムが停止する点を除いて、この更新のためにサービスを停止する必要はありませんし、動作中のプロセスに影響もありません。サーバの集合体としてシステムを構成することで、既存のシステムと比較してシステムを動作させたままでのシステム更新が単純になります。各コンポーネントはそれぞれ異なるアドレス空間で動作していますから、例えばメモリ管理機構ですら、他の (独立した) コンポーネントに影響を与えることなく更新できます。カーネルサブシステム間でポインタのやりとりをするようなシステムでは、他を変更せずにひとつのコンポーネントだけを更新することは非常に困難です。この分野は研究成果が実を結んだ数少ない、しかも他のほとんどのシステムでは実現できないとても重要な分野の一つです。

謝辞

30年もの年月に渡りMINIXプロジェクトに協力してくださった数百の人々に深く感謝します。残念ながら、あまりにも多過ぎて全ての方のお名前をここに記すことはできません。それでもなお、際立った貢献をしてくれたKees Bot、Ben Gras、Philip Homburg、Kees Jongenburger、Lionel Sambuc、Arun Thomas、Thomas VeermanそしてJan-Mark Wamsには特に名前を挙げて感謝の意を表明したいと思います。本研究はオランダ科学研究機構 (Netherlands organization for scientific research)、欧州研究評議会先進予算 (European Research Council Advanced Grant) 227874、および欧州研究評議会Proof of Concept予算297420の支援を受けて運用されました。

参考文献

(訳文の間違いなどはGitHubのIssue Tracker、あるいは twitter:@keiichishima よりご連絡ください。)