モノリシックカーネル

ウィキペディア

モノリシックカーネル

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2024/12/27 01:12 UTC 版)

モノリシックカーネルの概念図

モノリシックカーネル（monolithic kernel）とは、オペレーティングシステム（以下、OSと略記）におけるカーネルの構造、および設計思想を指す。「入出力機能やネットワーク機能、デバイスのサポートなどOSの一般的な機能」をカーネルと同一のメモリ空間に実装・実行する手法を言う。

代表的なモノリシックカーネルOSとしては、古典的なUNIXとその派生OSがあげられる。

モノリス(monolith)とは「一枚岩」の意であり、モノリシック(monolithic)とは「一枚板の」という形容詞である。ここでは「一体化したカーネル」という意味で使われている。

マイクロカーネルとの比較

OSの構成要素を単一のメモリ空間で実行するモノリシックカーネルに対し、OSを構成する幾つかの要素・機能をカーネル空間から切り離し、外部モジュール化するなどで実装する手法をマイクロカーネルと呼ぶ。

モノリシックカーネルの設計思想および概念それ自体は旧来より存在するが、マイクロカーネルという概念・実装の登場によって、対概念として要請され、命名された（レトロニム）。

カーネル実装方式とその議論

モノリシックカーネル方式は、より近代的な設計手法とされるマイクロカーネル方式のOSに比べ、OSの機能のほとんどすべてが単一のメモリ空間で行なわれるゆえ、同一の処理を行う際に費やされるコンテキストスイッチやプロセス間通信などによるオーバーヘッドは相対的に少ないものとなり、実効パフォーマンスにおいて有利であるといった見解がある。実際にプロセッサの動作クロックが数MHz - 数十MHz程度に留まっていた時代には、乱発されるコンテキストスイッチなどの実行コストの問題は深刻なものであった。1980年代にデビューした商用UNIXは、そのほとんどがモノリシックカーネル方式を採用している。

しかし、プロセッサの処理速度は20世紀末から21世紀初頭にかけて長足の進歩を遂げた。また、マイクロカーネル側の実装における高速化技法の進展、必要に応じて一部パフォーマンスを要求されるサブシステムのみカーネル空間に取り込む実装も登場し、モノリシックカーネルのパフォーマンスにおける原理上の優位性は小さくなった。

2005年現在では、純然たるモノリシックカーネル方式で開発する利点は少ないとする意見に収束して来ている。しかし、同等の機能を実装した場合にその原理上実行時の（コンピュータのメモリ上の）OSカーネルのフットプリントを比較的小さなものに留めておきやすいこと、ノンプリエンプティブ (non-preemptive) 制約を付加すれば、サービス実装を行う時に考慮するべきことが減り、開発が楽になることなどが利点として挙げられる。

一方、モノリシックなカーネルにさまざまな機能を取り込むことで巨大化することによる欠点・弊害としては、OSの機能を動的に切り替えたり更新したりすることが（マイクロカーネルと比較した場合に）困難なものになりやすいことなどが挙げられる。

研究開発の世界では、カーネルの機能を最小限にとどめるマイクロカーネルが主流になった1990年代当初、モノリシックカーネルは時代遅れとされてきた。しかし、実装レベルでの差が動作上の致命的な設計問題であるはずもなく、現在では必要な機能を必要な性能レベルで提供できれば問題ないという形での議論終結が図られている。

Solaris / HP-UX / AIXや日本の国産UNIXの系統も全てモノリシックカーネルを基礎とするカーネルを使用している。また、x86系PCでのUNIX互換機能提供を目指して作られたLinuxでは基本的にモノリシックカーネルを採用しているが、実行時に読み込むカーネルモジュールを設けるなど、実行時の柔軟性を高めている。

Windows NTは、当初よりマイクロカーネル方式での実装を模索していたが、オーバーヘッドを削減するためにNT 4.0でWindowsサブシステムとグラフィクスデバイスドライバがカーネル空間から直接見える様に修正された。さらにWindows 2000以降では、ハードウェア管理機能の一部をマイクロカーネル直轄のモジュールとしての外部モジュールからカーネル制御部本体による制御方式に切り替えており、純粋なマイクロカーネルから外れた実装になっている。NT4.0では800キロバイト弱だったNTOSKRNL（Windows NT系のカーネルシステム）のフットプリントは、Windows XPでは2メガバイト強にまで肥大している（ただしWindows Vistaにおいては、動作の安定性やシステム全体の堅牢性に対する配慮から一部「先祖返り」を起こしている）。 マイクロカーネルとしての構造は依然残されているため、マイクロカーネルとモノリシックカーネルの折衷をとったハイブリッドカーネルとでも呼ぶべき実装になっている。

またMachから派生したmacOSも、BSDサブシステムやファイルシステム、ネットワークなどをカーネル空間に統合しており、純粋なマイクロカーネルから離れた実装になっている。Windowsと同様、マイクロカーネルとモノリシックカーネル両方の利点を活かした設計である。

有名な論争

モノリシックカーネルとマイクロカーネルについては、Linuxの作者リーナス・トーバルズとMINIX（ミニックス）の作者アンドリュー・タネンバウムの1992年の論争が有名である。

モノリシックカーネルの採用例

• Linuxカーネル
• Classic Mac OS（8.6まで。以降はナノカーネル）
• MS-DOS
• OpenVMS
• UNIXカーネル
• Windows 9x系 (Windows 95 / 98 / Me)
• IBM i

外部リンク

• Linux is obsolete(英語) - リーナス・トーバルズとアンドリュー・タネンバウムの論争
• ディベート：リナックスは時代遅れだ

ウィキペディア小見出し辞書

モノリシックカーネル

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/09/16 14:38 UTC 版)

「カーネル」の記事における「モノリシックカーネル」の解説

詳細は「モノリシックカーネル」を参照 モノリシックカーネルでは、全OSサービスはひとつのカーネル空間内に存在し、カーネルスレッド上で実行される。この手法は強力なハードウェアアクセスを提供する。UNIXの開発者ケン・トンプソンは、モノリシックカーネルの方がマイクロカーネルより実装が容易だとしている。主な欠点はシステム構成要素間の依存関係の複雑さである。例えば、デバイスドライバにバグがあっただけでシステム全体がクラッシュするし、大きなカーネルは保守が非常に困難である。 Unix系OSが伝統的に採用してきたモノリシックカーネルは、OS中核機能とデバイスドライバを全て含んでいた。デバイスドライバ、スケジューラ、メモリ管理、ファイルシステム、ネットワークのプロトコルスタックなど、多くのプログラムが必要とするがライブラリとしてユーザー空間で実行することができない機能は、全てカーネル空間に置かれた。それら全サービスへのアクセスを可能にするため、数多くのシステムコールがアプリケーションに対して提供されている。 必要とされないサブシステムを伴って最初からロードされるモノリシックカーネルは、より汎用的な意味ではあるが、特定ハードウェア向けに設計されたものよりもチューニングが可能である。LinuxやFreeBSDなどの現代のモノリシックカーネルはUnix系OSであり、実行時にモジュールをロードする機能を備えており、必要に応じて容易に機能を拡張でき、同時にカーネル空間で動作するコード量をなるべく最小に抑えることができる。モノリシックカーネルには次のような長所がある。 関係するソフトウェアが少ないので、より高速である。 カーネルは1つのソフトウェアであるため、ソースコード量もコンパイル後の実行ファイルの大きさも小さくなる。 コードが少ないのでバグも少なく、結果としてセキュリティ問題も比較的少ない。 モノリシックカーネルはシステムコールの延長で動作する部分がほとんどである。システムコールは一般にテーブル構造で保持されるインタフェースであり、ディスク操作などのカーネル内サブシステムへのアクセスを行う。プログラム内でライブラリルーチンを呼び出すと、その中で要求をチェックしてコピーし、システムコールに渡す。したがって、それほど重い呼び出しではない。Linuxカーネルはモノリシックだがかなり小さくできる。これは、ローダブル・カーネル・モジュール機能と、カスタマイズが容易なためである。実際、フロッピーディスク1枚にカーネルだけでなく多数のユーティリティを搭載し、それだけで完動するOSとすることもできる（最も有名な例として muLinux（英語版） がある）。このカーネルを小型化できる能力があるため、Linuxは組み込みシステムで急速に採用が増えている（組み込みLinux）。 このようなカーネルはOSの中核機能とデバイスドライバから成り、実行時にモジュールをロードする機能を備えている。それらによって、下層のハードウェアについての豊富で強力な抽象化を提供する。それらは単純なハードウェア抽象化の小さなセットを提供し、サーバと呼ばれるアプリケーションを使ってさらなる機能を提供する。この特定の手法でハードウェア上の高度な仮想インタフェースを定義し、プロセス管理、並行性管理、メモリ管理といったスーパーバイザモードで動作するいくつかのモジュールでOSサービスを実装し、システムコールでそれらを呼び出せるようにしている。しかし、このような設計には以下のような短所や制約がある。 カーネル内のコーディングは難しい。標準Cライブラリが使えず、デバッグにはGNUデバッガなどのソースレベルのデバッガを必要とするためである。そのため、開発中はコンピュータを頻繁にリブートする必要がある。これは単に開発者だけの問題ではない。デバッグが難しいということはバグをつぶすのが難しいということであり、カーネル内にバグが残存しやすいということでもある。 カーネル内のバグは重大な副作用を引き起こす。カーネル内の関数はどれも特権状態で動作するので、全く無関係なデータ構造を（カーネル空間内でもユーザー空間内でも）容易に壊すことができる。モジュール群は同一アドレス空間で動作するので、バグによってシステム全体をダウンさせることがある。 カーネルは肥大化しやすく、肥大化すると保守が困難になる。 コードの結合度が強く、モジュール化して分離したとしても、その分離を正しく行うのは困難である。 移植性が低い。動作させるアーキテクチャごとに書き直しが必須となる。