オペレーティングシステム - みる会図書館


検索対象: 386BSD カーネルソースコードの秘密
106件見つかりました。

1. 386BSD カーネルソースコードの秘密

第 4 章カーネル内部サービス (kern/config. c 、 kern/malloc. c) イバに対する参照があった場合、更新後は新しいドライバの間違った場所を指している、というような、 よくあるケース ) を未然にキャッチすることができない。ドライバのデバッグも可能とするクラッシュプ ルーフなドライバ機構を開発することは不可能ではないが、それには、この問題に対する、もっとずっ と高度でエレガントな解決方法、すなわちポータルを使う方法が必要になる ( ポータルに関する前述の 議論を参照してほしい ) 。 第 4 段階では、コンフィギュレーションの中でも、より高位の抽象レベルを、オペレーティングシステ ムの他の部分と統合することによって、具体化する。このとき、コンフィギュレーションにおけるカー ネルの役割は、ユーザープロセスとして実行されているコンフィギュレーションプログラムから改訂さ れたメソッドを受け取る、単なる仲介者の役割に過ぎなくなる。 このプログラムにはコンピュータのハードウェアを評価する機能があるが ( カーネルが構成できない 残りのデバイスを探す ) 、ユーザープログラムを実行できる状態にカーネルを持ち込むには、このファイ ルによって開始された仕事を完了させるために、最初のプログラムである / sbin / config を初期化プロ セス (/sbin/init) が起動する必要がある。 開発の最終段階である第 5 段階では、複数のオペレーティングシステムのインターフェイスを収東で きるようなインターフェイスレジストリの開発が行われる。このレジストリを使えば、たとえば 386BSD は ( そして他の研究用オペレーティングシステムも ) 別のオペレーティングシステムのドライバや標準イ ンターフェイスを使えるようになり、変換プロトコルの使用によって、そうした別のオペレーティング システムの資源も、自分自身の標準と互換の方法により、利用することが可能になるだろう。 このように相互に交じり合うことのできるカーネルプログラミング環境ができれば、その結果として 平均的なユーザーにも、各種インターフェイスの競合や、既存の一般的なオペレーティングシステム環 境とのシームレスな相互互換性といった利益が及ぶことになる。そうなればユーザーは、 386BSD 独自 のドライバが開発されるのを待つ必要なく ( 仮に誰かがそうするとしての話だが ) 、自由に最良のハード ウェアを選択して使うことができるようになる。 4.3.8 コンフュレーションのトボロジーとクラスタリング 将来に向けてコンフィギュレーションに関して考慮すべきもうひとつの点は、構成されるアイテムの トボロジーである。現在のところ、すべてのソフトウェアモジュールとハードウェアデバイスは、シン プルな閉路のない有向グラフ (directed acyclic graph) によって記述できるものと考えられる。現在の システムによる需要は、これで十分に満たすことができる。しかし、私たちが VAX のデュアルポート コントローラ ( 同じデバイスを指している 2 つのコントローラ ) に関して体験したことだが、より複雑な 構成が、閉路をもつ (cyclic) グラフや、無向グラフ (non-directed graph) 、あるいはその両方によって しか記述できなくなったときには、大きな問題が発生する。 たとえばプロセッサクラスタによるアーキテクチャの場合、複数のデバイスを調停するには、各モ ジュールと、それらが管理するデバイスの結合状態を記述するのに、閉路をもつ複数のグラフを共有す る形式になる。この種のアーキテクチャで、コンフィギュレーションの順序と相互依存性を管理するに 188

2. 386BSD カーネルソースコードの秘密

オペレーティングシステムは、シンプルな実行モジュールの単なる集合ではない。実際は、もっと複 雑な機構である。オペレーティングシステムの心臓は、基本カーネル (basickernel) だ。人体における 心臓と同様に、基本カーネルも複雑なオペレーティングシステムにおいて、他のすべてのサプシステム が独立して機能できるようにリソースを配給するための手段を提供している。基本カーネルがないと、 オペレーティングシステムの他の部分は " 生きていけない " のだ。一方、仮想メモリシステムは、オペ レーティングシステムの頭脳である。それは、一時的な、あるいは永続するメモリの保存とアクセスが、 この仮想メモリシステムを介して行われるからだ。人間の頭脳と同様に、一時的なメモリは、新しい事 項を永続するメモリに保存する前に組み立てるための作業空間として使用される。 さらに、カーネルのモジュールおよびサプシステムは、生物におけるそれらと同じく相互依存してい る。 1 個のモジュールやサプシステムに発生した病気が、他の部分で症状を見せることさえある。たとえ ば動物のシステムにおいて血液の循環が不十分になると、その問題は神経系の不調 ( たとえば、めまいや 目のかすみ ) として現れることがある。同じように、もし基本カーネル ( 心臓 ) の中で、あまり長い間、 割り込みがプロックされると、ネットワークシステム ( 神経系 ) は十分な速度で応答することができなく なり、その結果としてサービスの効率が落ちるか、あるいは失敗してしまう。基本カーネルの中のカー ネルメモリアロケータの設計がますくてメモリのリークを起こすようだと ( これは商用 OS ではよくあ る問題だが ) 、仮想メモリシステム ( 頭脳 ) はメモリの損失に悩まされ、いつかはシステム障害 ( system failure) に至る。だから、オペレーティングシステムを正しく設計するには、カーネル全体の理解が不 可欠なのだ。 カーネル内の、その他のモジュールおよびシステムについても、やはり同じように、生物システムの 中にそれらと類似した存在がある。ファイルシステムは、オペレーティングシステムの骨格をなす構造 である。情報の通路であるソケットは、オペレーティングシステム全体の神経系構造の輪郭を形成し、 lnternet ネットワークプロトコルは、その情報のための神経伝達物質として働く。この 2 つのモジュー ルを組み合わせると、オペレーティングシステムの中枢神経系が完成する。 しかし、オペレーティングシステムの設計を生物学的な比喩で説明するのにも限界がある。生物シス テムの最大の目的は、生存と自己複製にあるからだ。制御力学に関する我々の知識は、いまだ初期の段 階にあり、オペレーティングシステムは、この 2 つの機能をまだ実現していない * 1 。この比喩の目的は、 完全な類似性を得ることではなく、人体の構造を説明する解剖学の教科書と同じような構成によって、 カーネルの各部分の役割、責任分担、相互依存性に関する理解を促すことにある。このシリーズの目的 * 1 このシリーズの全般で議論の対象となる、エラー復旧とクラスタリングという 2 つのシンプルな機構は、 オペレーティングシステムの機能の一部を複製しようとするものではあるが、生物システムの優雅さと比 べれば、これらは初歩的な手段にすぎない。 7

3. 386BSD カーネルソースコードの秘密

第 9 章 POSIX オペレーティングシステム機能 (kern/execve. c 、 kern/descrip. c) これまでの各章では、カーネルの中でも特定のオペレーティングシステムのプログラムインターフェ イスに比較的依存しない領域について説明してきた。しかし、オペレーティングシステムに固有な性質 を、いつまでも避けているわけにはいかない。効率的な実装にはある程度、密接な相互作用が必要だか らだ。カーネルの中でも、 POSIX / UNIX のセマンティクス * 訳注 1 と深い関連があるのが、プログラム の実行 (program execution) とファイル記述子に対する操作 (file descriptor 叩 erations) の、 2 つの部 分である。これらは、どんなオペレーティングシステムにも存在するが、あるオペレーティングシステム の特定の実装を操作するには、明快なものにせよ、微妙なものにせよ、セマンティクスの違いが重要な 影響を与える。 UNIX オペレーティングシステムの変種という狭い領域に限っても、この 2 つの機構に は実装によって大きな違いがある。これらは、カーネルの抽象レベルの中でも、ある意味では " 一番上の そのまた上 " のレベルにあり、オペレーティングシステムの API(application programminginterface) が厳密にどのような意味を持つかによって、非常に大きく影響される。 プログラムのローディングには、実行ファイルのフォーマット、実行のためにロードされるイメージ の配置、引数の渡しかた、プログラム起動のセマンティクスなど、どれも欠くことができない。これら はすべて、 POSIX のプログラムロード関数である execve() の要素である。これは BSD と iBCS の両 方の仕様を満足させるもので、ファイルフォーマットやさまざまな詳細については BSD * 1 の、 X86 アー キテクチャ * 2 に関する詳細については iBCS の仕様に従う。 UNIX システムで使用されるファイル記述子は、他のオペレーティングシステムのものと同様に、オー プンされたファイルのインスタンスを「ハンドル」を使って参照する。とはいえ、このカーネルには、 POSIX 標準のファイル記述子に特有の性質が、数多く埋め込まれている。これは、インターフェイスの特 性が ( プログラムのローディングの場合のように明白にではなく ) 微妙に影響を及ばす一例である。実装 の詳細に関するセマンティクスを理解することによって得られる、細かい性格に関するこうした知識は、 複数のオペレーティングシステムのカーネルに依存しないセマンティクスをエミュレータ (emulator) 機 構の中に実装するのに、不可欠なものとなる。 9 」 386BSD の実行ファイルフォーマットエミュレータ 386BSD の実行可能ファイルフォーマットエミュレータ (executable file format emulator) は、この システムにとって新しい目標のひとつであり、設計上の概念のいくつかを Mach のエミュレーションライ プラリから受け継いでいる。 Mach では、ユーザープログラムはエミュレーションライプラリを介してシ ステムを呼び出す。このエミュレーションライプラリが提供するシステムパーソナリティ (personality) * 訳注 1 こではプログラムインターフェイス。 * 1 BSD べースのシステムは、 Bell 研究所の 32V UNIX から自然に成長したものであり、アーキテクチャに固 有な部分の詳細については標準化されていない。 * 2 iBCS 仕様は、 X86USLSVR4 システムを詳しく定義するものであり、その本質は純粋な SVR の追求であ るため、 BSD システムは意図的に無視されている。 442

4. 386BSD カーネルソースコードの秘密

4.3 386BSD のコンフィギュレーション : kern/config. c 4.3.1 抽象レベルと階層構造は、コンフ拌ュレーションにどう影響するか レベルでは、対応するオペレーティングシステムのレイヤ ( これも、より上位の層へと順に上がってい 最も低い抽象レベルにおいては、検知と衝突の回避が主な目的である。けれども、それより上の抽象 響を与える問題なのである。 ( つまりネットワークのレイヤモデル ) のように、オペレーティングシステムのすべての抽象レベルに影 実際のオペレーティングシステムのコンフィギュレーションというものは、ちょうどネットワーク管理 ギュレーションは単一の抽象レベルで解決できるという考えがあるが、これはまったくの誤解である。 オペレーティングシステムのコンフィギュレーションについて、よくある考え違いとして、コンフィ 特定のホストコンピュータのシステム管理者は、オペレーティングシステムの中に構成可能なサプシス レイヤを昇順に辿っていくうちに、ある層において、 く ) のニーズに即した管理と資源利用が行われる。 このオペレーティングシステムを実行している 177 な問題が生じた。 の機能を整理整頓しようという空しい試みであった。このアイデアは 4.4BSD で復活したが、やはり同様 * 19 BSD 4. ld のカーネルプログラムは、ディレクトリごとに 1 個のグループに分割されたが、これはカーネル * 18 階層構造を強制的に崩した結果、モジュール間の相互作用が不透明になってしまうのが原因である。 の詳細を見極めるまでは、高いレベルの実体を初期化することはできない。 おいては、依存性によって初期化の順序付けが要求されるのが普通である。だから低いレベルの数多く に対応する、数種類のインターフェイスを持つものが多いからだ。初期化とコンフィギュレーションに しかしながら、階層構造は必要である。これらのモジュールには、階層構造のさまざまな部分に個別 ても、必ず直接的な成果を得られるわけではない、ということを示す一例である ) 。 の現在のバージョンでは、それぞれが対等である状態のまま存在している ( これは、レイヤを顕在化し ルは、ファイルシステムのトボロジーでは正しく表現できないのである。このため、これらは 386BSD あって、こうしたモジュールによって実装されたオペレーティングシステムのレイヤリングと抽象レベ て、より管理しやすくしようとする試みがなされたことがある * 19 。しかし、このアプローチには問題が をたどれば ( BSD の古いバージョンにおいて ) これらのモジュールの一部をカテゴリ別にまとめて分離し るが、各モジュールは抽象レベルの階層構造の異なるレベルにおいて、さまざまな動作を実行する。元 386BSD オペレーティングシステムの場合、カーネル自身が数個のモジュールによって構成されてい おくべきである * 18 。 好都合なアプローチだが、場合によって破綻してしまうような・・絵空事 " であることは、常に認識して 出すために、こうした何層もの抽象レベルを単一のレベルに圧縮する設計が試みられた。これは確かに システムにおけるコンフィギュレーションでは、システム管理者が管理しやすいフラットな配置を作り ベルに存在するかもしれない ) プログラムの実体は意識されない。過去のさまざまなオペレーティング す役割によって識別されるのであり、サプシステムを構成している ( その層より低いさまざまな抽象レ テムが存在することを意識する。管理者の視点から見ると、これらのサプシステムは、それぞれの果た

5. 386BSD カーネルソースコードの秘密

第 2 章アセンブリ言語によるエントリとプリミティブ ( i386 / loco 「 e. s ) オペレーティングシステムの設計を請け負ったアーキテクトは、恐ろしいほど多くの、互いに矛盾し た責務に直面する。どんなオペレーティングシステム設計にも高いレベルの抽象概念が存在し、それら すべてを調停し、明白に定義しなければならないのだが、それらはオペレーティングシステム ( カーネ ル、ユーティリティなど ) と、その下で実行されるユーザープログラムの間にあるだけでなく、オペレー ティングシステムそのものの中にも存在する ( ファイルシステム、ドライバ、アプリケーションインター フェイス、などなど ) 。 こうした抽象的な需要のほかに、そのオペレーティングシステムが実行されるハードウェアの設計に 関する現実的な問題も同時に存在する。オペレーティングシステムを実動させるには、そのシステムが プロセッサのアーキテクチャを利用する方法、具体的には、たとえばオペレーティングシステムという プログラムをメモリにロードして実行を開始させる方法までも、その設計に盛り込まなければならない。 このように仕様を固めていくプロセスは、新しい領域の先駆となる場合、特に複雑である。 386BSD の場合もそうで、これ以前に、 BerkeleyUNIX から ( そういう意味では、どのような UNIX もだが ) 386 アーキテクチャへの、非独占的かっドキュメント付きの移植を公開した人は誰もいなかったし、この移植 を行う案内となる参考資料も存在しなかった ( ただし私たちは、それよりも前に PDP ー 11 、 VAX 、 68000 、 32000 の各アーキテクチャへの移植を行った経験があったけれども ) 。 どのアーキテクチャも、どのコンピュータ設計も、それぞれが別々の方法でこれらの領域を扱ってい るので、設計上の最初の選択が非常に重要である。マシンに依存しない設計と、ある特定のアーキテク チャの上でコードを実行しているという事実との兼ね合いのため、移植の初期段階から、難しく影響が 大きい判断を、数多く下さなければならない。そして残念ながら、こういった選択の結果は、しばしば 表面的には矛盾しているように見えるのである。 2.1 locore. s の開発に際しての決定事項 この移植作業を始める前に Berkeley から発せられた最初の質問は、「 locore を書くのに、どのくらい時 間がかかるか」というものだった。開発の手順は、 locore. s ファイル、マシン依存コード (machdep ・ c) 、 そしてドライバの順序だが、最初の 10C 。 re が大きな障害となるからだ。どうしてそれほど難しいかと いうと、オペレーティングシステムのカーネルを構築するための基本的なフレームワークを提供するた めに、正しく決定しなければならない事項が、数多く存在するからである。 このファイルには、 386/486/Pentium プロセッサのアーキテクチャに対するマシン依存性を核とす る、主に初期処理のためのアセンプリ言語が含まれている。 1989 年に私たちが、 BerkeleyUNIX の 386 のための新しいバージョンの作成に着手したときは、このファイルの雛形となるようなマスターコピー を持っていなかった。また、 386 アーキテクチャに関する経験もなく、他の 386 UNIX からのコーディ ング例も入手できなかった。これらのアクセスは非常に厳重な管理下に置かれていて、この種のファイ ルを書くための秘訣のようなものさえ管理されていたのだ。だから私たちは、独自に 10C0 て e . s を " 発 明 " しなければならなかった。 36

6. 386BSD カーネルソースコードの秘密

序 は、どのようなオペレーティングシステムでも評価できる能力、またそれを進化させる能力を読者に身 に付けていただくことであり、著者である私たちは、読者が 1 個のオペレーティングシステムのカーネ ルを完全に理解できるように、このシリーズを構成するつもりである。 8

7. 386BSD カーネルソースコードの秘密

まえがき 俯瞰 : 386BSD と " 実世界 " 私たちの記述が提示する全体像は、安定性、標準との互換性、生の " ビットレベルの " 性能、そして拡 張性、スケーラビリティに関する観察を組み合わせたものである。商品向きのクオリティーを持ったオ ペレーティングシステムを目指したものではないので、この全体像を、その他の領域 ( たとえば個々の商 品との互換性の表示 ) にまで拡張する試みは行っていない。また、テストやデバッグのサポートは、 の仕事には含まれていない。商品化されたシステムのほどんどが品質の低下を示しているとしても、そ れは恒久的な状態と見るべきではなく、もし顧客が十分な教育を得てスモークスクリーンの向こう側を 見通せるようになれば、市場からの圧力によって改善されるものと考えるべきだ。だから、宣伝広告の スモークスクリーンの向こうにある、現実のオペレーティングシステムの基本を見通すことができるよ うに、その全体像を提示することも、本書の重要な役割である ( 商品システムに関わっている人々から は、必ずしも歓迎されないだろうが ) 。 オペレーティングシステムの事実と幻想とを手際よく切り分けるには、鋭利な刃物が必要である。私 たちの仕事が、その刃先を少しでも鋭く研ぐ助けになることを望む。そして、ポジテイプで建設的な方 向に、それを使っていただきたい。 最後に。この体系 (system) が、この場で一挙に完結することはないだろうと、私は最初にお断 りした。そして疑いもなく、その言葉通りの結果を、読者は御覧になったわけだ。しかし私は自分 の鯨学を、造りかけの塔の上に起重機を乗せたまま残されているケルンの大聖堂さながら、未完成 のまま終えるのである。なぜなら、小さな建て物ならば初代の建築技師たちが自ら完成させること もできようが、壮大な建築、真実の伽藍に置く最後の冠石は、必ず後代の手に委ねることになるか らだ。神よ、むしろ私に何物も完成させ給うな。この本にしてもすべてが下書き、いや、下書きの 下書きに過ぎない。ああ、時間、カ、金、忍耐 ! Herman Melville, Moby Dick, Chapter 32 13

8. 386BSD カーネルソースコードの秘密

まえがき この本の構成 『 386BSD ソースコードシリーズ 1 』では、最小限度の設計によるカーネルに必要な、基本的なカーネ ルソースファイルを解説する。どのオペレーティングシステムにも、最小限の形式と構造のモデルが存 在し、その多くは、同じような要求事項に対処するために、同じような機構を使用している。また、カー ネルのプリミテイプな機構と、ターゲットコンピュータのプロセッサのために実装されるカーネルプロ グラムの詳細についても、他のカーネルプログラムをそのプロセッサに対応させるために記述する必要 がある。カーネル自身は 1 個のプログラムであり、このプログラムをより管理しやすく簡潔なものにす るために、一群のサービスが使用される。カーネルは、 1 個のアプリケーションプログラムを実行するだ けでなく、プロセスという概念を使って、数多くのアプリケーションプログラムを同時に実行できなけ ればならない。そして最後に、個々のプロセスへのインターフェイスには POSIX 標準オペレーティング システムインターフェイスを反映する必要があるが、この実装ではカーネルが直接これを実装している。 本書は、以下の 5 つのセクションにわかれている : 基本カーネルの紹介 ( 第 1 章 ) 、マシンに依存しな いカーネル ( 第 2 章、第 3 章 ) 、カーネルの内部サービス ( 第 4 章 ) 、プロセスオプジェクト ( 第 5 章から 第 8 章まで ) 、 POSIX オペレーティングシステムの機能 ( 第 9 章 ) 。 このシリーズ全体のための、教科概要と講義メモを含むインストラクターズガイドが、現在準備され つつある。詳細は出版社 (Peer-to-Peer Communications, lnc. ) に問い合わせていただきたい。 本書の使いかた この本は実際に使用できる基本オペレーティングシステムカーネルの、本物の実装について説明する ものなので、『 386BSD Fromthelnside-Out 』など、オペレーティングシステムの構造と設計に関する 386BSD のソースコードと、その他の情報 抽象レベルから最も高いレベルに至るまで層を重ねて構築される様子を見ることができる。 また、コードは最初の章から順番に見ていくのがいい。そうすれば基本カーネルのコードが最も低い ・実装を拡張できる限界を明らかにする。 競合する選択肢と、そのコストに関するトレードオフを説明する。 ・各章で提示された概念を具体化する。 本と併用していただきたい。また、次の目的で例と課題を設定してある。 る。 BSD を 386 PC へ移植する作業は、 Dr. DobbIs JournaI に、 Porting UNIXto the 386 という 17 励する目的で私たちが始めたものであり、何度もメジャーリリースおよびマイナーリリースを重ねてい 386BSD は、 1989 年にオペレーティングシステムとネットワークの設計に関する新しいアイデアを奨 11

9. 386BSD カーネルソースコードの秘密

2.4 locore. s の関数と用語 プートストラップ環境に関して将来検討を要する領域のひとつは、この start ルーチンの実行中に 自己再配置 (self-relocating) を行わせるかどうかである。こでいう自己再配置とは、プートストラッ プがカーネルを物理アドレスのどこにでも、どういうシーケンスでもロードできるようにし、カーネル のスタートアップコードである start が、自分の実行アドレスを検知してページテープルを適切にアロ ケートするということである ( つまり、アドレス 0 から開始することを前提としない ) 。 このようにすれば、システムは他のオペレーティングシステムと共存して実行することが可能になり、 386BSD のために予約されたメモリを、同じマシン上に存在する他のオペレーティングシステムのメモ リとは独立して管理することができるようになる。こうすれば 386BSD と Windows などが ( 注意が必 要だが ) 共存できる。この分野での準備作業はすでに始まっているが、これは非常に繊細な設計分野で ある。なぜなら 386BSD と Windows は、どちらもすべてのメモリ資源を制御する方針で設計されてい るからだ。言ってみれば、どちらも自分の池で一人で遊びたいのである。したがって、このような変更 に関する技術的な制約は、何か隠れた理由というより、むしろ協議と準拠の問題なのである。 プートストラップ環境に関して将来検討を要する、もうひとつの領域は、要するにシステムの最初の ロードを取り巻く周辺の環境を、どう決めるかということだ。システムのプートストラップに、たとえ ば 386BSD の下層にあるオペレーティングシステムとして常駐する機能を持たせてもいいだろう。この " OS " は、たとえばシステムを構成する際に必要に応じてドライバをロードするのに、 BIOS を使えるわ けだ。しかし残念ながら、初期の UNIX システムには、シンプルな DOS システムが利用している BIOS のような、豊富な実行環境を持っていなかった * 8 。 BIOS は、そこそこ充実したプログラミング環境を 提供し、オペレーティングシステムを構成する前にそのシステムをロードしなければならないという、 " 卵が先か鶏が先か " 的状況を回避することができる。このシステムは BIOS を使ってロードできるので、 それからシステム構成を読み出したり、たとえば root ファイルシステムをマウントする前に root デバ イスのドライバをファイルシステムからロードすることも可能になる。こうすれば、最初からシステム 全体を動的にロードできるのだ。それどころか、デバッガをオペレーティングシステムよりも前にロー ドして、このエントリコードを最初からシングルステップ実行してデバッグすることさえできるだろう。 これを実現するには、カーネル自身のほかに複数のモジュールをシステムにロードし、動的に再配置す る必要がある。 これらすべてを行うには、かなりの量の仕事が新たに必要になることは明らかだが、将来の設計に関 するこの議論の目的は、このランタイムスタートアップの設計では妥協しているが、もっと単刀直入な プロセスとして考える余地もあるということを、読者に伝えることである。 * 8 通常、 ROM はディスクのプートプロックをロードするだけだった。このプートプロックには、より大規模 なプートストラップをロードし、最終的にはカーネルプログラムをロードするための、シンプルなディス クドライバが入っていた 43

10. 386BSD カーネルソースコードの秘密

まえがき テム (TheUFSFilesystem) 』がある。現在のオペレーティングシステムは、 基本的なファイルおよびサプシステムによって構成されている。 「ソースコードがあれば十分か」 これらの巻で説明される こまで論じたところで発せられる質問は、典型的には次のようなものである。「ソースコードと実 際に使えるシステムが手元にあるのに、システムカーネルがどう構築され設計されたかについて書かれ たものを、どうしてわざわざ読まなければならないのか。そんなものを読まなくても、カーネルを理解 し、修正し、変更するのに必要なものは、すでに揃っているではないか」というのだ。特に 386BSD の 豊富なソースコード ( ユーティリテイやアプリケーションプログラムのソースも含まれている ) は、以前 はソースコードやシステムソフトウェアに対するアクセスをまったく禁じられていたユーザーにとって は、すべての願いをかなえてくれる存在に見えるだろう。 私たちは、 10 年単位で数えるような長い間、オペレーティングシステムのソースコードを相手に仕事 をしてきたが、そんな私たちでさえも、 20 年以上の開発期間に、変更を受け続け、文字どおり何千人年 ものマンパワーを注がれてきたカーネルから、何か新しいものを発見して驚くことがある。だから、ソー スコードを持っているのは確かに力強いことだが、数多くの設計者たちの意図について概要をつかむに は、それだけでは不十分なのである。もしそれで十分だとしたら、たとえば力学の初歩を学ぶ学生は、 古典力学に関するランダウの画期的な著作 * 3 を読むだけで、 ( ハミルトンの方程式を含む ) 古典力学のす べての法則を導き出すのに必要な情報を得ることが可能であり、補助テキストや講義など他の情報は一 切必要ないということになる。たぶん世の中には、そのくらいできるよと主張する天才的な物理学者も 何人かいるかもしれないが、圧倒的な多数は、一般にさまざまな情報源から、より多くの洞察を得る必 要があるのだ。要するにこれは、天才にとっても即座に理解するのは困難な領域のひとつなのである。 いまや実動中のオペレーティングシステムを所有しているというだけでは、十分ではない。理屈に合っ た改訂や拡張を行うには、その細部までの文書化と調査・説明が絶対に必要なのだ。そうしなければ、細 部の難解さによって構造が見えなくなり、設計の繊細な側面がかき消されてしまうので、オペレーティ ングシステムのアーキテクチャと実装が正しいものかどうかを判断するのが困難になる。そのような場 合、製品の実装上の改善と、オペレーティングシステムにおける基本的なパラダイムシフトに関わる改 善とを判別できなくなるかもしれない。実際、ソースコードが意図的に不明暸に書かれ、そのシステム に関する他の " ソース " がなければパラダイムを認識できないようになっている可能性さえある。 現代のオペレーティングシステムは、コードがあればいいという程度の存在とは、まったくかけ離れ ている。確固とした存在理由が必要なのだ。背後から支える論理がしつかりしていなければ、おそらく 実装も不確かだろう。そのような場合、理想的な姿に近づけるには、理論と実装の両方に、かなりの改 訂が必要となるだろう。 * 3 10 L. D. Landau, & E. M. Liftshitz, Mechanics , Pergamon Press, Oxford ( 1960 ) 。