ハッカーの系譜⑨オープンソースの巨人たち (6) Linuxは優れたアーキテクチャーしかサポートしない

December 20, 2016 08:30
by 牧野武文

CPUの欠陥設計はLinuxでは採用しない

リーナスは、DEC社のAlphaへの移植作業を1993年に始めて、ほぼ1年で完成させた。マイクロカーネルではなく、マイクロカーネルの最適化手法を使って、なおかつ移植性を高める独自の工夫をしていった。リーナスは、この時点で、他のプラットフォームにも移植することを視野に入れて、Alphaへの移植は単なる移植作業ではなく、移植性を高めるLinuxの改造作業だと考えて、移植を進めていった。

Alphaへの移植作業が終わると、リーナスはいよいよ本格的な移植作業のために、68K、SPRAC、Alpha、PowerPCといった当時主流だったCPUの機能を比較検討し始めた。すると、リーナスは面白いことを発見した。それは、各CPUは機能も動作もまったく異なるが、その背景にある考え方は驚くほど共通した部分が多いということだ。

例えば、メモリーページング機能はどのCPUにも存在している。メモリーを小さなページという単位で扱うために、メモリーを効率的に利用することができる。空き地をただ駐車場として解放したら、後先を考えない人がじゃまなところに駐車して、たくさんの車が止めることはできなくなってしまうが、駐車区画の線を引いてやるだけで、空き地に最大限の車を駐車できるようになる。それと似たようなものだ。

メモリーページングの実現の仕方は、CPUによって当然異なっている。しかし、リーナスは各CPUの機能を見るのではなく、メモリーページングという考え方に注目をして、Linuxのコードを書いていった。すると、どのCPUでも通用するコードになり、しかも効率のいいコードになったのだ。つまりどのCPUであっても、背景にある考え方は似通っているが、具体的な実装方法が各CPUのアーキテクチャーによって異なっているだけだったのだ。そのような機種ごとの特殊事情を無視して、原理原則に従ったコードを書いてやれば、それが各CPU上でも効率的なコードになる。必ずそうなるとは断言できないが、リーナスは明らかに移植性の高いコードを書くコツをつかんだ。

もちろんうまくいかず、どうしても特定のCPUのためだけに、余計なコードを書かなければいけないこともあった。しかし、リーナスはそのようなCPUを批判する。「アーキテクチャーが、その細部で一般的な設計から逸脱するのは、往々にして設計そのものに欠陥があるからだ」と手厳しい。

リーナスは、優れた設計思想の機能だけをLinuxに取りこみ「各CPUの欠陥設計」に基づく機能については無視するようにした。このようにしていくことで、次第に各CPUが優れた設計思想にもとづいた機能だけを実装することを期待したのだ。

この「優れた設計思想だけをLinuxは受け入れる」という発想は、CPUの機能だけでなく、システムの仕様にも適用された。たとえば「ファイル名は14文字まで」という仕様を、リーナスは「ばかげたもの」と批判する。このような不自由な仕様にも対応するようにOSを開発してしまうと、長いファイルを扱えるシステムとファイル名をやり取りするときにトラブルが起きるからだ。リーナスは「こんなバカげたことをやっているのはマイクロソフトだけである」と批判している（現在Windows10ではバス名を含め最大260文字）。

徹底したモジュール化が分散同時開発を可能にした

リーナスは、Linuxのカーネルをモジュール化する設計も行っていた。多数の人間で、分担して同時並行で開発を進めるためだ。リーナスは、それまでに共同作業をおこなって、複数の人間が議論をすることの無意味さに辟易していた。結局、共同作業で開発をおこなっても、合理的なゴールに全員が向かうわけではなく、多くのエンジニアが自分のやりたい手法こそ合理的だといって議論がまとまらない。最後には宗教論争のようになってしまい、まったく前に進まなくなることもある。だったら、モジュール化をして、モジュール間通信のプロトコルだけを定義しておき、それぞれが各モジュールを担当して開発をした方がいいと考えた。できあがったモジュールを動かしてみれば、「処理速度」という客観評価ができるので、御託ばかり並べてたいしたモジュールが組めないエンジニアの仕事は、いったん捨てて、だれかが作り直せばいい。リーナスは、すでにインターネットを使って、ボランティアを募り、ネット上で開発をしていくことを考えていた。

このモジュール化には、思わぬ副産物もあった。Linuxのような大がかりなプログラムの場合、たとえばファイルシステムを変更したとしたら、それがLinuxのあちこちに影響してしまう。この影響を検出して、修正をあてていくというのは、非常に手間のかかる作業で終りが見えない仕事になりがちだ。しかし、モジュール化されていれば、他のモジュール担当者は、通信プロトコルに変更さえなければ自分のモジュールを点検する必要すらない。

Linuxでも問題になったライセンス方式

Linuxが2.0になる頃には、ほぼモジュール化が完了していた。ネットを通じた有志に開発するモジュールを割り振り、完成したモジュールはリーナスの元に送られて、組み合わされて動作確認がおこなわれるという開発体制がここで確立した。

しかし、このモジュール方式は開発の手法としては優れていたものの、オープンソースという点ではちょっとした問題を引き起こした。リーナスはLinuxは当然オープンソースにすべきだと考え、GPL（グニュパブリックライセンス）を適用することにした。しかし、どこからどこまでがLinuxなのかという定義が、モジュール方式では難しくなってきてしまったのだ。

カーネルをモジュール方式としたのだから、実行は当然ランタイムローディング方式になる。つまり、必要なモジュールがでてきてから、そのモジュールをメモリーに読みこんで実行するという方式だ。余計なモジュールをメモリー空間に置かないことで、メモリーの節約にもなるし動作も軽快になる。しかしモジュールはカーネルの一部なのだろうか、それともアプリケーションと同じ扱いなのだろうか。

特に問題になったのは、周辺機器のドライバーだ。ドライバーを開発するには、その機器の深い知識が必要となる。そのため、メーカーのエンジニアでなければ書けるものではない。Linux用のドライバーをわざわざ開発して、提供してくれるメーカーもあった。しかし、そのドライバーはそのメーカーの著作物とするのが妥当で、勝手にオープンソースにするわけにはいかない。メーカーの中には、著作権や企業秘密を守るために、バイナリーは提供するが、ソースコードは提供しないというところもあった。

リーナスは、この問題に早い段階で気がつき、ドライバー類はLinuxの一部とは見なさないという姿勢を表明した。そのため、各メーカーはLinuxに対してドライバー類を提供しやすくなり、Linuxが使いやすいOSになっていった。

オープンソースであるがゆえに安定するOS

Linuxは、個人ユーザーや個人ユーザーの発言力が大きい研究機関などで採用されていったが、一般のPCユーザーや民間企業は距離をおいていた。一般のPCユーザーにとっては確かに扱いが難しかった。インストールも、WindowsやMac OSのようにすべて自動で、終わるのを待っているだけで良いというわけにはいかない。アプリケーションを使うだけの一般ユーザーにとってはLinuxはあまり意味がなかった。Linuxの最も優れた点は、改変ができるという点だ。コードが読めて、書ける人でなければ、Linuxの価値を最大限に引き出すことできない。

民間企業も当初は導入に及び腰だった。Linuxを使って、何か障害が起きたときに「誰が責任を取ってくれるのだ」ということを心配した。しかし、商用のOSを使って障害が起きた場合でも、メーカーはそもそも責任を負わない契約になっている。オープンソースのOSは、多くの人がソースコードを検証しているので安定性もある。一方で、一社が作る商用のOSは、その企業のエンジニアしかソースコードを見られないの。そのため安定性が確保できるかどうかは、その企業の努力まかせになっている。

オープンソースは、フリーウェアと混同され「どこの馬の骨がつくったのかもわからないガラクタ」だという誤解もあった。もちろん、オープンソースにすれば自動的に安定性が担保されるわけではない。そのコミュニティーが大きければ安定性が確保でき、小さなコミュニティーではOSのような複雑で大きなシステムを開発は難しい。

Linuxは、リーナスというプロジェクトマネージメントの天才がいたために、類まれなOSに育っていった。リーナスの慧眼は、自分一人で開発するのではなく、膨大な人数の人たちを巻きこみ、権限を与え、まかせることで、世界中にLinuxコミュニティーを作っていった。これはエンジニアだけのことではなく、その後Linuxを販売し、サポートするレッドハット社も生みだすことになった。

(その7に続く)