2006年02月11日

マイクロカーネル

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動: ナビゲーション, 検索

マイクロカーネルとはオペレーティングシステムの設計思想、及びそのようなOSのカーネル部の名称である。OSが担う各種機能のうち、必要最小限のみをカーネル空間に残し、残りをユーザーレベルに移すことで全体の設計が簡素化でき、結果的に性能も向上できるという考え方。カーネル本体が小規模な機能に限定されるので「マイクロカーネル」と呼ばれるが、必ずしも小さなOSを構成するとは限らない。

マイクロカーネルの出現に伴い、従来型のOSを「モノリシックカーネル」と呼ぶようになった。

特徴

純粋なマイクロカーネルでは、まずカーネル空間で提供される機能を、メモリ空間の仮想化、プロセス制御、プロセス間通信に限定し、割り込みなども全て通信にマップする。その上でファイルシステムやデバイスドライバといった準カーネル機能をそれらのアプリケーションとして実装し、ユーザー空間で動作させる。場合によってはそれらの機能セットをサーバと呼ばれる単位で複数動作させる。

このような形態を持つ事のメリットは、

* OS開発効率の向上(機能拡張、デバッグなどを容易に行える)
* システム全体を止めずにカーネル以外のOSのアップデートを行うことができる
* 必要な機能のみを提供するアプリケーションに特化したOSを構築することが容易になる

などである。また一般にマイクロカーネルでは資源の抽象度が高く、マルチプロセッサ対応やネットワーク透過の通信が自然に実装できるため、大規模な資源利用には有利である。


反面あらゆる場所でプロセス間通信を利用する為、機能相互のオーバーヘッドが大きく、モノリシックカーネルと同等の機能を実装した場合、数パーセントから数倍のロスが出る場合がある。特にコンテキストスイッチのコストを避けるため、必要な機能をカーネル空間に移し、見た目上モノリシックカーネルのように動作させる場合もある(co-location)。

歴史

マイクロカーネルは「UNIXの再設計」という観点から始まっている。

UNIXはファイルという概念でリソースを統一し、ファイルを扱う小さなプロセスをパイプでつないで相互通信させることにより、コンパクトかつ高機能なOS設計に成功した。しかしその後の利用環境の変化に伴い、必ずしもファイルとして扱えないリソースが増加している。例えばネットワーク通信はソケットという概念で行われるが、ソケットはファイルではない。結果的に、後付けで似て非なるコードがOSを肥大化させるという事態が発生したといえる。

OSがたくさんのコードから成る事の直接的な問題点は、

* カーネル自体が占めるメモリ領域(カーネル空間のフットプリント)が大きくなる
* 移植性やメンテナンスに不利

といったものである。さらに、計算機資源の増大に伴いマルチプロセッサや仮想メモリといった、UNIX開発時に想定していなかった概念が出現しており、それらを含めたOS概念のリファインが必要と考えられた。


そこで、「大規模な資源」と「高速な通信」を念頭において「相互通信するプロセスによる協調動作」というUNIXの発展理念に至ったのがマイクロカーネルである。UNIXではファイルを中心概念としていたが、マイクロカーネルではプロセスと通信に主眼を移し、割り込みやI/Oといったあらゆる資源が徹底的に抽象化されている。

なお、この時古くなった計算機資源の再利用も考慮されていた。つまり、移植性が高くコンパクトなOSを使えば、旧式のシステムであってもネットワーク上に接続して資源として活用する事ができるという考え方である。


実際に実装されたMachでは、当初の予想通りコード量の削減には成功した。抽象度が高く、見通しの良いマイクロカーネルはトレンドとしては妥当であり、この時は将来有望な物と見なされている。

しかし問題はマイクロカーネルのパフォーマンス問題が予想以上に大きかった事である。初期のMachは純粋なマイクロカーネルではなく、BSDサーバとの複合カーネルだったがそれでも25%ほどのロスがあり、さらにこれを完全なマイクロカーネルに移行した場合、機能によっては数倍遅くなるという結果が出ている。さらに言えば、マルチプロセッサが浸透するという技術予測が外れた事も大きい。

一方メンテナンス性の面では、典型的なモノリシックカーネル実装であるLinuxの成功により、カーネルの複雑さは心配されたほど大きな問題ではない事が明らかになった。


こうして、一時は「全てのOSはマイクロカーネルに移行する」と考えられていたが、90年代中ごろにはそのような見方は下火になっている。

ただし、以上の問題はマイクロカーネルに利点がないという事は意味しない。実際にNeXTSTEP/Mac OS XやBeOSはマルチプロセッサ対応やCPU移行時の高い移植性など、マイクロカーネルOSであることの利点を活かしている。またLinuxのモジュール機構などは実質マイクロカーネル的な概念であり、利点は利点としてとりいれる傾向があるといえる。

一方マイクロカーネルも性能面での解析が進み、現在第二世代といわれる新しい実装が出現してきている

代表的な実装例とその特徴

* OS-9
o 6809のために設計された、最初の商用マイクロカーネルOS、当時はマイクロカーネルという用語は無く、有用性も理解されておらず、マイコン用途にしてはオーバースペックであった。
* Mach
o カーネギーメロン大学によってもっとも初期に開発され、マイクロカーネルの代名詞ともなったもの。Mac OS XやNEXTSTEP、MkLinuxで使用されている
* L4
o 第二世代マイクロカーネル。高速なメッセージ通信の実装によって、マイクロカーネルの欠点と言われた「メッセージ通信の多さによる非効率性」に対処することを目的にあげており、各種の実装上の工夫によってモノリシックカーネルに遜色ないパフォーマンスを出している。
* Hurd
o GNU によって UNIX 代替をめざし開発されたカーネル。トレンドにあわせ設計がたびたび変更されたため、アナウンス以来長らく登場が待望されていたが、近年動作可能なものが発表された
* Windows NT
o Machをベースにマイクロソフト独自実装のマイクロカーネルを利用。しかし、WindowsNT 4.0以降、パフォーマンス重視の為、各種ドライバをカーネルモードで動作させるようになり、すでにマイクロカーネルの範疇を逸脱しているという考え方もある。(カーネル参照)
* BeOS
o 独自のマイクロカーネル実装。優れたマルチプロセッササポートや、PowerPCからx86への移植の早さはマイクロカーネルの当初の理想を体現した物といえる。現在各種のフリー実装が進んでいるが、ここでもマイクロカーネルの利点が発揮されている。
posted by シンビアン at 08:31| Comment(0) | TrackBack(0) | Series60プログラミングテクニック | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。

この記事へのトラックバック
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。