Loading AI tools
オペレーティングシステムの中核となる部分 ウィキペディアから
カーネル（英: kernel）は、階層型に設計されたオペレーティングシステム (OS) の中核となる部分で、アプリケーションとハードウェアの架け橋である。具体的には、システムのリソースや、ハードウェアとソフトウェアの連携を管理する[1]。そのほか、通信制御を行うことが多い。
 |
オペレーティングシステムの基本コンポーネントとして、カーネルはメモリ、CPU、入出力を中心としたハードウェアを抽象化し、ハードウェアとソフトウェアがやり取りできるようにする。また、ユーザープログラムのための機能として、プロセスの抽象化、プロセス間通信、システムコールなどを提供する。
これらのタスクはカーネルによって方式が異なり、設計や実装も異なる。モノリシックカーネルは全てを一つの仮想アドレス空間に格納されたコードで実行して性能を向上させようとする。マイクロカーネルはサービスの大部分をユーザー空間で実行し、コードの保守性とモジュール性を向上させようとする[2][3]。多くのカーネルはこの二つのカテゴリのいずれか、あるいは中間である。
全てではないが、多くのオペレーティングシステム (OS) はカーネルを内包する。ハードウェアとソフトウェアの間の通信を管理するソフトウェアとしてのカーネルは、性能、メモリ効率、セキュリティ、プロセッサのアーキテクチャなどが複雑に絡んだ問題への妥協的解答である。
多くの場合、ブートローダーがカーネルを特権モードのプロセスとして起動する[注釈 1]。しかし、初期化が完了すると、カーネルはいわゆるプロセスとしては存在せず、ディスクアクセスなどの高い特権レベルを必要とする処理を必要としたときにユーザプログラムから呼び出される機能の集合体として存在することになる。カーネルの処理の流れはユーザープロセスの処理の流れの延長上にあり、システムコールによってカーネルに処理がわたり、終了するとユーザーに戻っていく。初期化時のコンテキストはそのまま消えるようにする設計もあるが、「アイドルプロセス」とか「collects」と呼ばれる、プロセッサが何もすることがないときに実行されるコードに流用される設計とすることもある。省電力のため、プロセッサが「休む」ような命令を繰り返すようなコードとすることも多い。
カーネル開発はプログラミングの中でも複雑で難しいタスクのひとつと考えられる。オペレーティングシステムの中核部であるということは、高い性能を要求される最重要なソフトウェアであり、正しく設計し実装することは難しい。カーネルはユーザプログラムの互換性や移植性を考慮する必要などから、設計が制限されることがあり、そのことがさらに開発を難しくしている。
カーネルの仕事はコンピュータのリソースを管理し、他のプログラムがそれらのリソースを使って動作できるようにすることである[1]。典型的なリソースとしては以下のものがある。
リソース管理に必要な重要な観点は、実行領域（アドレス空間）の定義とその領域内のリソースへのアクセスを調停する保護機構である[1]。
また、カーネルは一般にプロセス同士の同期と通信の手段も提供しており、プロセス間通信 (IPC) と呼ぶ。
カーネルは自前でそれらの機能を実装していることもあるし、何らかのプロセスに委任していることもあるが、後者の場合はプロセス間で機能へのアクセスを可能にするIPCを提供する必要がある。
最後に、カーネルはそれら機能群へのアクセスを要求する手段をプログラムに提供しなければならない。
カーネルの主な仕事はアプリケーションの実行を許可し、ハードウェア抽象化などの機能によってそれをサポートすることである。
プロセスは、アプリケーションがアクセスできるメモリの範囲を定義する[5]。カーネルのプロセス管理は、ハードウェアの持つメモリ保護機構を考慮しなければならない[6]。
カーネルはアプリケーションを実行するためアドレス空間を設定し、アプリケーションのコードを含むファイルをメモリにロードし、プログラムのためのコールスタックを設定し、そのプログラムの所定の位置に制御をわたすことで実行を開始する[7]。
マルチタスク可能なカーネルは、ユーザーから見て実際にそのコンピュータが同時実行できるプロセス数よりも、多数のプロセスが同時並行して実行されているかのようにみせかける。一般にシステムが同時並行して実行できるプロセス数は、そのシステムの持つCPU数に等しい（同時マルチスレッディングをサポートしている場合はそのかぎりではない）。
プリエンプティブ・マルチタスクシステムでは、カーネルは各プログラムにタイムスライス（そのプログラムがCPU上で実行される連続時間）を与え、プロセスからプロセスへと高速に切り換えていくので、ユーザーから見ればそれらのプロセスが同時並行して実行されているように見えるのである。カーネルは次に実行すべきプロセスを決定し、タイムスライスの長さを決定するスケジューリングアルゴリズムを持つ。一般にプロセスには優先度が設定される。カーネルはそれらのプロセス間の通信手段も提供する。これはプロセス間通信 (IPC) と呼ばれ、パイプ、共有メモリ、メッセージ、RPC、ソフトウェア割り込みなどがある。
ほかに協調型マルチタスクもあり、各プロセスは自らカーネルに制御を戻すまで割り込まれずに実行を続けることができる。制御をカーネルに戻すことを "yielding" と呼び、プロセス間通信の際や何らかのイベントを待つ際に行われ、そのときにカーネルが別のプロセスを動作させる。古い Windows や Mac OS はこの方式だったが、コンピュータの性能向上に伴ってプリエンプティブ方式に切り換えた[8]。
オペレーティングシステムは、マルチプロセッシング（SMPやNUMA）をサポートすることもある。この場合、複数のプログラムやスレッドが複数のプロセッサ上で動作する。そのようなシステムでカーネルを動作させる場合、「リエントラント（再入可能）」あるいは「割り込み可能」になるよう大幅な改造が必要となる。これはつまり、何か処理をしている最中にほかからも要求を受け付けるということである。この改造ができれば、異なるプロセッサ上で動作するプログラムが同時にカーネルを呼び出しても大丈夫になる。カーネルは複数のプロセッサからのメモリアクセスを同期させる方法（スピンロックなど）も提供しなければならない。これはメモリ管理とプロセス管理にまたがる問題である。
カーネルはシステムの全メモリへの無制限のアクセスが可能で、ユーザープロセスの要求に応じて安全なメモリアクセスを提供しなければならない。このための第一歩はページング方式やセグメント方式による仮想アドレッシングである。仮想記憶方式では、カーネルは物理アドレスを別のアドレス、つまり仮想アドレスに変換する。これにより、各プログラムは（カーネル以外では）仮想空間上唯一のコードに見え、プログラムが互いに他のプログラムを破壊することを防止する[7]。
多くのシステムで、あるプログラムの仮想アドレスはメモリ上にないデータを指していることがある。仮想アドレッシングによるインダイレクション層は、本来なら主記憶 (RAM) になければならないデータをハードディスクなどの補助記憶装置に退避させることを可能にする。結果としてOSは物理的な容量以上のメモリをプログラム群に提供可能となる。RAMにないデータがあるプログラムで必要になった場合、CPUはカーネルにそれを知らせ（ページフォールト）、（必要なら）カーネルが使われていないメモリブロックの内容をディスクに退避させ、必要なデータをそのメモリブロックに復帰させる（ページ置換アルゴリズム）。すると、プログラムは要求を行った時点から処理を再開させることができる。これをデマンドページングと呼ぶ。
仮想アドレッシング方式では、仮想空間をカーネル用の部分（カーネル空間）とアプリケーション用の部分（ユーザー空間）に分けることができる。アプリケーションはカーネル用メモリにアクセスできないので、アプリケーションにバグがあったとしてもカーネルにダメージを与えることはない。この根本的な分離は多くの汎用カーネルで実際に使われているが、別の方式を採用したカーネルの研究も行われている（たとえば、Singularity）。
メモリ管理のもうひとつの機能として、カーネル内の各モジュールやデバイスドライバが使用するメモリの割り当てがある（動的メモリアロケーション）。
実際に何らかの作業をするには、OSはコンピュータに接続された周辺機器にアクセスする必要があり、周辺機器はその開発元などが書いたデバイスドライバを通して制御される。デバイスドライバはOSがハードウェアデバイスとやりとりするためのプログラムであり、OSに対して何らかのハードウェアを制御・通信するための情報を提供する。ドライバはアプリケーションにとっても重要で不可欠である。ドライバの設計目標は抽象化である。ドライバの機能はOSの定めたインタフェースからデバイス固有のインタフェースに変換することである。理論上、デバイスは適当なドライバがあれば正しく動作する。デバイスドライバは、ビデオカード、サウンドカード、プリンター、スキャナー、モデム、LANカードなどに対応して存在する。一般的なデバイスドライバの抽象化レベルを次に示す。
たとえば、ユーザー向けに何かを画面に表示する場合、アプリケーションがカーネルに要求し、その要求がディスプレイドライバに送られ、ディスプレイドライバが実際の文字やピクセルの描画を行う[7]。
カーネルは使用可能なデバイスの一覧を保持しなければならない。この一覧は、事前に知られている場合（たとえば、組み込みシステムでは利用可能なハードウェアが変われば、カーネルを書き換える）、ユーザーが設定する場合（古いPCや個人用に設計されていないシステムなど）、OSが実行時に検出する場合（プラグアンドプレイ）がある。プラグアンドプレイのシステムでは、デバイス管理は最初にさまざまなバス（PCIやUSB）上をスキャンして実装されたデバイスを検出し、対応するドライバを探す。
デバイス管理は各OS固有の部分であり、カーネルの設計によってドライバの扱い方は異なるが、一般にカーネルはドライバが物理的にデバイスにアクセスするための入出力ポートやメモリ空間を用意する必要がある。デバイスへのアクセスはコンテキストスイッチを引き起こしたり、CPUを浪費したりすることになりやすく、性能オーバヘッドの元となるため、デバイス管理の設計は重要である。
意味のある作業を実行するには、ユーザプログラムはカーネルの提供する全サービスにアクセスできなければならない。これはカーネルによって実装が異なるが、多くは標準CライブラリやAPIが提供され、そこから対応するカーネル機能が呼び出される[9]。
カーネル機能を呼び出す方法は主にCPUがどのような機能を提供しているかに依存する。カーネル空間とユーザー空間が分離されている場合、ユーザープロセスが直接カーネルを呼び出すことはできない。たとえば以下のような技法を採用する。
カーネル設計において重要な観点として、障害（フォールトトレラント性）と悪意ある動作（セキュリティ）からの保護（プロテクション）サポートがある。この2つは通常明確には区別されず、明確に区別しようとするとリングプロテクションでは対応できなくなる[1]。
カーネルが提供する機構または方針は、いくつかの基準で分類できる。
などである。
階層型プロテクションは[12]、一般に「CPUモード」でサポートされる。ハードウェアサポートによる単純で効率的な方法は、MMUにメモリアクセスのたびにその妥当性をチェックさせるもので、その機構をケイパビリティベースドアドレッシングと呼ぶ[13]。ただし、多くの商用コンピュータアーキテクチャではMMUがケイパビリティをサポートしていない。
代替手法は、階層型プロテクションでケイパビリティをシミュレートするものである。この場合、保護されたオブジェクトはアプリケーションがアクセスできないアドレス空間になければならない。カーネルもそのようなメモリ空間のケイパビリティのリストを保持する。ケイパビリティによって保護されたオブジェクトにアプリケーションがアクセスしたい場合、システムコールを行い、カーネルが実際のアクセスを代行する。これにはアドレス空間の切り替えを必要とするため、オブジェクト間で複雑なやりとりが必要なシステムでは性能が低下するが、現代のOSはアクセス頻度が低いオブジェクトや性能を要求されないオブジェクトについてはこの方式を採用している[14][15]。保護機構をより高い階層でシミュレートする方式も可能だが（たとえば、直接サポートされていないハードウェアについてのページテーブルを操作してケイパビリティをシミュレートするなど）、性能上の問題がある[16]。言語ベースの保護を選択するシステムでは、ハードウェアサポートがなくても問題にならない[17]。
カーネル設計における重要な点として、セキュリティの機構と方針を実装する抽象化レベルの選択がある。カーネルのセキュリティ機構は、高度なセキュリティをサポートする上で重要である[13][18][19][20][21]。
1つの方式として、ファームウェアとカーネルでフォールトトレラント性をサポートする方式があり、その上に悪意ある動作に対するセキュリティ方針を構築し（必要に応じて暗号機構を追加する）、一部の責任をコンパイラに委任する。コンパイラやアプリケーションレベルへのセキュリティ方針の責任委譲の方式を一般に「言語ベースのセキュリティ」と呼ぶ。
現代の主流のOSの多くは重要なセキュリティ機構が欠如しているため、アプリケーションの抽象化レベルでの適切なセキュリティ方針実装ができないことがある[18]。一般にカーネルサポートがどうであれ、アプリケーションで任意のセキュリティ方針を実装可能だとされているが、間違いである[18]。
現代の一般的コンピュータは、ハードウェアが強制した規則を使ってプログラムのデータへのアクセスを許可している。プロセッサは動作を監視し、規則に違反したプログラムを停止させる（たとえば、カーネル空間のメモリを読み書きしようとしたユーザプロセスを停止させるなど）。ケイパビリティをサポートしていないシステムでは、プロセスは相互に隔離されたアドレス空間で動作する[22]。ユーザプロセスがカーネルを呼び出すことは、上述したシステムコールの技法を使って統制されている。
代替手法として言語ベースの保護（プロテクション）がある。言語ベースのプロテクションシステムでは、カーネルは信頼されている言語コンパイラが生成したコードのみ実行を許可する。そしてその言語は、セキュリティに違反するようなコードをプログラマが書けないように設計されている[17]。
この方式には次のような長所がある。
一方、次のような短所がある。
言語ベースのプロテクションを採用したシステムとしては、JXやマイクロソフトのSingularityがある。
エドガー・ダイクストラは論理的観点から、バイナリセマフォにおける不可分なロックとアンロック操作だけで、プロセス間の任意の協調作動を実現できることを証明した[23]。しかしそのような方式は一般に安全性や効率性が欠如しており、メッセージパッシング方式の方が柔軟性が高い[24]。他の方式もいくつかあり、現代のカーネルでは共有メモリやRPCなどのシステムをサポートしていることが多い。
入出力デバイスを並行して協調作動する他のプロセス群から一様に扱えるようにするというカーネルの考え方は、Per Brinch Hansen が提唱し実装したのが最初である（似たような考え方は1967年にも示唆されていた[25][26]）。Hansen はその説明で、「共通の」プロセス群を「内部プロセス」、入出力デバイスを「外部プロセス」と呼んでいる[24]。
物理メモリと同様、アプリケーションがコントローラのポートやレジスタに直接アクセスすることを許可すると、コントローラが不正作動したり、システムがクラッシュすることになる。それに加えて、デバイスの複雑さに応じて対応するプログラムは非常に複雑化することがあり、しかも複数の異なるコントローラを使うことがある。そのため、デバイスを管理するためのより抽象化されたインタフェースを提供することが重要である。この抽象化を提供するのは一般にデバイスドライバや Hardware Abstraction Layer (HAL) である。アプリケーションは必要なら頻繁にデバイスへのアクセスを要求する。カーネルはシステムに接続されたデバイスの一覧を何らかの方法で保持しなければならない。これはBIOSや各種システムバスの機能（PCI/PCIeやUSB）を使ってなされる。あるアプリケーションがあるデバイス操作を要求すると（たとえばディスプレイに文字を表示する）、カーネルは対応するドライバ（たとえばビデオドライバ）に要求を送らなければならない。するとそのドライバがデバイスに対して必要な処理を行う。マイクロカーネルの場合、この際にプロセス間通信 (IPC) が使われる。
もちろん、上述したタスク群や機能群の提供方法は設計や実装の面でさまざまである。
「機構と方針の分離」の原則は、マイクロカーネルとモノリシックカーネルの哲学の間でかなり大きな相違がある[27][28]。ここで、「機構」はさまざまな「方針」の実装を可能とするものであり、「方針」は特定の「操作のモード」である。たとえば「機構」面では、ユーザーがログインしようとしたとき認証サーバを呼び出してアクセスを認めるべきか否かを決定するということが考えられる。一方「方針」面では、認証サーバがパスワードを要求し、データベース内の暗号化されたパスワードと照合するかもしれない。機構が汎用的であれば、機構と方針が同一モジュールに統合されている場合よりも方針の変更（たとえば、パスワードの代わりにセキュリティトークンを使うなど）がより容易になる。
最小のマイクロカーネルでは非常に基本的な方針のみが含まれ[28]、その機構はカーネル上で動作させるもの（OSの残りの部分やアプリケーション群）自身がどのような方針（メモリ管理、高度なプロセススケジューリング、ファイルシステム管理など）を採用するか決定することを可能にする[1][24]。一方モノリシックカーネルは方針の大部分をカーネル内に含む傾向があり、結果としてその上の部分の自由度は制限される。
Per Brinch Hansen は機構と方針の分離のための主張を展開した[1][24]。すなわち、この分離が不適切であることが既存のOSで本質的技術革新が見られないことの主要因だとし[1]、コンピュータアーキテクチャにおける共通課題だとした[29][30][31]。モノリシック設計は、従来の商用システムで一般的な保護技法である「カーネルモード」と「ユーザーモード」に分離するアーキテクチャ（いわゆるリングプロテクション）から生まれた[32]。そのアーキテクチャでは、保護（プロテクション）を必要とするモジュールを可能な限りカーネルに含めようとする[32]。このようなモノリシック設計と特権モードの関係が機構と方針の分離における重要な問題として再注目されている[1]。実際「特権モード」のアーキテクチャ技法は保護機構とセキュリティ方針を融合させる傾向があるが、これとは大きく異なるアーキテクチャ技法であるケイパビリティベースドアドレッシングではその2つを明確に区別し、自然にマイクロカーネル設計が可能となる[1]。
モノリシックカーネルはカーネルの全コードを同じアドレス空間（カーネル空間）で実行するが、マイクロカーネルでは多くのサービスをユーザー空間で実行しようとし、コードベースの保守性とモジュール性を向上させようとしている[2]。多くのカーネルは明確にどちらかに分類できるわけではなく、その中間の実装ともいうべきハイブリッドカーネルになっている。さらに特殊な設計としてナノカーネルやエクソカーネルが研究されているが、広く使われるまでには至っていない。エクソカーネルの例としてXenハイパーバイザがある。
モノリシックカーネルでは、全OSサービスはひとつのカーネル空間内に存在し、カーネルスレッド上で実行される。この手法は強力なハードウェアアクセスを提供する。UNIXの開発者ケン・トンプソンは、モノリシックカーネルの方がマイクロカーネルより実装が容易だとしている[33]。主な欠点はシステム構成要素間の依存関係の複雑さである。たとえば、デバイスドライバにバグがあっただけでシステム全体がクラッシュするし、大きなカーネルは保守が非常に困難である。
Unix系OSが伝統的に採用してきたモノリシックカーネルは、OS中核機能とデバイスドライバを全て含んでいた。デバイスドライバ、スケジューラ、メモリ管理、ファイルシステム、ネットワークのプロトコルスタックなど、多くのプログラムが必要とするがライブラリとしてユーザー空間で実行することができない機能は、全てカーネル空間に置かれた。それら全サービスへのアクセスを可能にするため、数多くのシステムコールがアプリケーションに対して提供されている。
必要とされないサブシステムを伴って最初からロードされるモノリシックカーネルは、より汎用的な意味ではあるが、特定ハードウェア向けに設計されたものよりもチューニングが可能である。LinuxやFreeBSDなどの現代のモノリシックカーネルはUnix系OSであり、実行時にモジュールをロードする機能を備えており、必要に応じて容易に機能を拡張でき、同時にカーネル空間で動作するコード量をなるべく最小に抑えることができる。モノリシックカーネルには次のような長所がある。
モノリシックカーネルはシステムコールの延長で動作する部分がほとんどである。システムコールは一般にテーブル構造で保持されるインタフェースであり、ディスク操作などのカーネル内サブシステムへのアクセスを行う。プログラム内でライブラリルーチンを呼び出すと、その中で要求をチェックしてコピーし、システムコールにわたす。したがって、それほど重い呼び出しではない。Linuxカーネルはモノリシックだがかなり小さくできる。これは、ローダブル・カーネル・モジュール機能と、カスタマイズが容易なためである。実際、フロッピーディスク1枚にカーネルだけでなく多数のユーティリティを搭載し、それだけで完動するOSとすることもできる（最も有名な例として muLinux がある）。このカーネルを小型化できる能力があるため、Linuxは組み込みシステムで急速に採用が増えている（組み込みLinux）。
このようなカーネルはOSの中核機能とデバイスドライバからなり、実行時にモジュールをロードする機能を備えている。それらによって、下層のハードウェアについての豊富で強力な抽象化を提供する。それらは単純なハードウェア抽象化の小さなセットを提供し、サーバと呼ばれるアプリケーションを使ってさらなる機能を提供する。この特定の手法でハードウェア上の高度な仮想インタフェースを定義し、プロセス管理、並行性管理、メモリ管理といったスーパーバイザモードで動作するいくつかのモジュールでOSサービスを実装し、システムコールでそれらを呼び出せるようにしている。しかし、このような設計には以下のような短所や制約がある。
マイクロカーネルとは、伝統的な「カーネル」から「サーバ」群に機能を移転するOS設計方針を意味し、最小化したカーネルだけをカーネル空間に残し、サーバ群を可能なかぎりユーザ空間で動作させる。マイクロカーネルでは、ハードウェアの単純な抽象化と最小のプリミティブ（システムコール）で最小のOSサービスを実装する（メモリ管理、マルチタスク、プロセス間通信など）。他の全てのサービス（ネットワークなど）は「サーバ」としてユーザ空間に実装される。マイクロカーネルはモノリシックカーネルよりも保守が容易だが、システムコール回数やコンテキストスイッチ回数が増大するために性能が低下する傾向がある。
どうしても特権モードでなければならない部分だけがカーネル空間に置かれる。それは、IPC（プロセス間通信）、基本スケジューラ（スケジューリング・プリミティブ）、基本メモリハンドラ、基本I/Oプリミティブなどである。スケジューラ本体やメモリ管理、ファイルシステム、ネットワークスタックといった大部分はユーザ空間で動作する。マイクロカーネルは、システム機能全体がプロセッサのシステムモードで動作する1つのプログラムになっているモノリシックカーネルの設計方針への反発から生まれた。マイクロカーネルを採用したOSとしては、QNXや GNU Hurd がある。マイクロカーネルは基本的に次のような長所を持つ。
多くのマイクロカーネルは、何らかのメッセージパッシングシステムを採用しており、サーバからサーバへの要求の転送を行う。一般にマイクロカーネルがそのためのポートを用意している。たとえばメモリ追加要求を送ると、マイクロカーネルのあるポートが開き、そこを通して要求が転送される。マイクロカーネルにメッセージが受信されると、その後はシステムコールのように処理される。これによってシステムアーキテクチャのモジュール性が高まり、システムがより整理され、デバッグや動的変更が容易になり、ユーザーのニーズに従ったカスタマイズが可能となる。AIX、BeOS、Hurd、macOS、MINIX、QNX といったOSは多かれ少なかれマイクロカーネルの設計方針を取り入れている。マイクロカーネル自体は非常に小さいが、システム機能全体を構成するコードを全て集めると、モノリシックカーネルよりも大きいことが多い。モノリシックカーネル支持派はまた、マイクロカーネル方式の2層構造によりOSの大部分がハードウェアと直接相互作用できなくなるため、決して小さくないコストが上乗せされ、システムの効率を低下させると主張している。マイクロカーネルは通常、アドレス空間定義部、プロセス間通信 (IPC)、プロセス管理といった最小限のサービスだけを提供する。ハードウェア処理といった他の機能はマイクロカーネルで直接扱うことはない。マイクロカーネル支持派は、モノリシックカーネルでのエラー（バグ）がシステム全体のクラッシュを引き起こすという欠点を指摘する。しかしマイクロカーネルでは、サーバがクラッシュしてもそのサービスを再起動することでシステム全体のクラッシュを防ぐ可能性がある。しかし、現にLinuxなどのモノリシックカーネルは年単位で安定動作している実績があり、このようなマイクロカーネルの利点がどれほど重要かは疑わしい。
ネットワーキングなどのカーネルサービスは「サーバ」と呼ばれるユーザ空間のプログラムとして実装される。サーバを停止・再起動するだけでOSを更新可能である。たとえばネットワークをサポートしていないマシンで、ネットワークサーバは起動する必要がない。サーバ群やカーネルの間でデータをやり取りする作業があるため、モノリシックカーネルにはないオーバヘッドが生じ、効率が低下する。
マイクロカーネルの短所はたとえば次のようなものがある。
マイクロカーネル方式では、OSの他の部分を通常のアプリケーションのように高水準言語で書くことができ、同一のカーネル上で異なるOS（のインタフェース）を使用することができる[24]。また動的にOSを切り換えたり、複数のOSを同時に使用することもできる[24]。
カーネルが巨大化するにつれて、さまざまな問題が明らかになってきた。最も明らかな問題はカーネルの大きさ（メモリ使用量）の増大である。これは仮想記憶をカーネル空間にも適用することである程度まで和らげられるが、全てのコンピュータ・アーキテクチャが仮想記憶をサポートできるわけではない[注釈 4]。カーネルのサイズを削減するため、不要なコードを削除するなどの改善が必要となるが、これはカーネルの各モジュール間の明らかにされていない依存関係があるために非常に困難である[注釈 5]。
マイクロカーネルと比較したときのモノリシックカーネルのさまざまな欠点から、1990年代の初期までにモノリシックカーネルは時代遅れと考えられるに至った。結果としてLinuxがモノリシックカーネルを採用したことでリーナス・トーバルズとアンドリュー・タネンバウムの間で有名な論争が発生した（アンドリュー・タネンバウムとリーナス・トーバルズの議論）[34]。この議論では、両者の言い分にそれぞれメリットがある。
モノリシックカーネルは設計が容易で、マイクロカーネルよりも迅速に成長することが期待できる。しかし、モノリシックカーネル内のバグは一般にシステムクラッシュを引き起こすのに対して、マイクロカーネルでは一部のサーバに問題が限定される。モノリシックカーネルの支持者は、不正なコードがカーネルになければマイクロカーネルの利点はほとんどないと論じる。どちらの側にも成功例がある。マイクロカーネルはロボットや医療用システムで使われており、各コンポーネントが別々の保護されたメモリ空間で動作する。これは最新のモジュールロード方式であってもモノリシックカーネルには不可能であろう。モノリシックカーネルは共有型カーネルメモリを使用するよう最適化されていて、マイクロカーネルのような低速なメッセージわたしとは異なる。
モノリシックカーネルはコード全体を同じアドレス空間（カーネル空間）に置くよう設計されており、一部の開発者はシステム性能向上に必須の特徴だとしている[35]。一部の開発者はうまく書けばモノリシックカーネルは極めて高効率になるとしている[35]。
1980年代から1990年代初めにかけてのマイクロカーネルの性能は低かった[36][37]。そういった初期のマイクロカーネルの性能を実測する研究が行われたが、性能が低い原因を深く分析することはなかった[36]。そういったデータが一人歩きし、カーネルモードとユーザモードの切り替え回数が増え[36]、プロセス間通信の回数が増え[36]、コンテキストスイッチの回数が増えたためだ[36] とみなされた。
そして1995年、マイクロカーネルの性能が低い原因として以下のことが推測されている[36]。
この時点でマイクロカーネルを効率化する方法はまだ研究途上であり、正しい技法の構築が求められていた[36]。
一方でモノリシックカーネルの設計の基盤となっている階層型プロテクション[32] でも、プロテクションの階層間でのやりとりには値（メッセージ）のコピーが必要であり、そのやりとりが増えるほど性能が低下することがわかっていた[38]。
Windows NT系などの商用OSでよく見られる。Appleの macOS も、カーネギーメロン大学のMachとFreeBSDのモノリシックカーネルのコードをベースとしたXNUというハイブリッドカーネルを採用している。マイクロカーネルの性能オーバヘッドを削減するため一部のサービス（通信プロトコルスタックやファイルシステム）をカーネル空間で動作させるが、一部のカーネルコード（デバイスドライバなど）はサーバとしてユーザ空間で実行する。これは、純粋なマイクロカーネルが高性能を提供できると示される以前、妥協的に考案された技法であり、マイクロカーネルにモノリシックカーネルの特性を一部取り入れて拡張したものといえる。
ハイブリッドカーネルではカーネルがモジュール化されているが、モジュールの大部分は同じカーネル空間内にロードされる。そのため、バグを含むモジュールをロードするとカーネルの動作が不安定になる可能性がある。マイクロカーネルの場合、カーネルとは全く別の空間でモジュールを動作させることができ、安全に評価することができる。モノリシックカーネルと比較したハイブリッドカーネルの長所を以下に挙げる。
モジュール群は何らかのモジュールインタフェースを使ってカーネルとやりとりする。そのインタフェースはOS固有ではあるが汎用化されており、常にモジュールとして分離実装できるわけではない。デバイスドライバにはモジュールインタフェース以上の柔軟性が必要なことが多い。基本的にモノリシックカーネルではカーネルとの呼び出しが1回で済むところを、ハイブリッドカーネルでは2回呼び出す必要がある。モジュール化の短所として次の事柄が挙げられる。
ナノカーネルは全てのサービスをデバイスドライバとして分離する。これにはたとえば最も基本的な割り込みコントローラやタイマーの制御も含まれる。これによりカーネルメモリはマイクロカーネルよりもさらに小さくなる[40]。
エクソカーネル (exokernel) はまだ実験段階のOS設計技法である。他のカーネルとの違いは、物理ハードウェアのプロテクションと多重化に機能を限定している点で、アプリケーションに対して全くハードウェアの抽象化を提供しない。このようにハードウェアのプロテクションをハードウェア管理から分離することで、利用可能なハードウェアを最大限に生かすように個々のプログラムを開発できるという利点が生じる。
エクソカーネル自体は非常に小さい。しかし、通常のOSの持つ機能をアプリケーション開発者に提供するためのライブラリ型OSを伴う。エクソカーネル型システムの最大の利点は、このライブラリ型OS機能を複数用意できるという点で、それぞれが異なるAPIを提供できる。たとえば同じシステム上で、高度なUIを持つアプリケーションを開発し、同時にリアルタイムシステム制御を行うアプリケーションも開発できる。
厳密にいえば、オペレーティングシステム（とカーネル）はコンピュータを動作させるのに必須ではない。プログラムはマシン上に直接ロードされ実行されることも可能であり、そのようなプログラムはOSのサービスや抽象化なしで記述しなければならない。多くの初期のコンピュータではそのような手法が一般的であり、プログラムを入れ替えるときにリセットとリロードが必要だった。その後、プログラムローダーやデバッガといった補助的な小さなプログラムがメモリに常駐したり、ROMからロードされるようになった。これらが初期のオペレーティングシステムのカーネルの元となった。直接実行の手法は今日でもゲーム機や組み込みシステムで使われているが[41]、一般に最近のコンピュータではオペレーティングシステムとカーネルが使われている。
1969年の RC 4000 Multiprogramming System では、小さな中核部の上で異なる目的のOS群を整然とした方法で構築するというシステム設計哲学を導入しており[42]、マイクロカーネル方式のさきがけとなっている。
UNIX以前の10年間、コンピュータは劇的に能力を向上させ、マシンの未使用時間を使う手法が求められた。この期間の主な開発のひとつがタイムシェアリングシステム (TSS) である。TSSは何人かのユーザーがCPUのタイムスライスをそれぞれ割り当てられる[43]。
タイムシェアリングシステムの開発は多くの問題を発生させた。ひとつの問題は大学のユーザーはCPU時間が欲しいというよりもシステムをハックしたがっているという点である。このためセキュリティやアクセス制御が1965年のMulticsプロジェクトの重要な課題となった[44]。もうひとつの問題は計算リソースの正しい扱い方である。ユーザーは計算リソースを使わずに画面を凝視することにほとんどの時間を費やしており、タイムシェアリング方式ではそのようなCPU時間を他のユーザーに与えるべきと考えられた。最終的に、メモリ階層の多層化が進み、リソースの分割が仮想記憶システムの開発へと繋がっていったのである。
UNIXの設計段階で、全ての高レベルのデバイスをファイルとして抽象化することが決定された。なぜならUNIX設計者は情報処理の目的をデータの変換であると考えていたからである[45]。
たとえば、プリンターもファイルとして抽象化され、データをそのファイルにコピーすると印字が行われる。他のシステムでは同様の機能を提供するにあたって、デバイスを低レベルに抽象化する傾向があった。デバイスもファイルも何らかの低レベルの概念の実体化である。システムをファイルのレベルで仮想化したことにより、ユーザは既存のファイル管理機能と概念で全てを扱うことができるようになり、操作が大幅に簡略化された。同じパラダイムを拡張して、UNIXはファイルを複数の小さなプログラムで操作するパイプの概念を可能とした。最終的な結果は同じであっても、このような小さなプログラム群を使うことで柔軟性が劇的に向上しただけでなく、開発も利用も容易になった。
UNIXでは、オペレーティングシステムは2つの部分で構成される。さまざまな操作を実行するユーティリティプログラム群とカーネルである[45]。プログラミングの観点から見ると両者の違いは小さい。カーネルは特権モードで動作するプログラムであり[注釈 1]、プログラムローダーとしての役割とシステムの残りの部分を構成するユーティリティプログラム群を監督する役割を持つ。そして、それらプログラムにロックと入出力サービスを提供する。つまり、カーネルはあらゆる場面に介在しているわけではなかった。
その後、計算モデルが変化し、UNIXの何でもファイルで表す手法が常に適用可能な方法ではなくなってきた。端末はファイルで表せるが（どちらも文字列を読み書きできる）、GUIはそのように扱うことはできない。コンピュータネットワークは別の問題を提起した。ネットワーク経由の通信はファイルアクセスに対応させることができるが、低レベルのパケット指向アーキテクチャはファイルというよりも離散的なデータの塊として扱う必要がある。コンピュータの機能が拡大するにつれ、UNIXのコードは増大していった。それはまた、UNIXカーネルのモジュール性が非常にスケーラブルなためでもあった[46]。初期のカーネルのソースは10万行ほどだったが、Linuxカーネルなどでは1300万行にもなっている[47]。
現代のUnix系OSは、モノリシックカーネルにモジュールローディング機能を加えたものとなっている。たとえば、Linuxカーネルを採用した各種Linuxディストリビューションや、BSDの子孫である FreeBSD、DragonFly BSD、OpenBSD、NetBSD、macOS などがある。
Appleは1984年、最初のMac OSを同社のパーソナルコンピュータMacintoshに同梱して発売した。後継のmacOSはDarwinをベースとしており、4.4BSDユーザーランドとMachカーネルを統合したXNUと呼ばれるハイブリッドカーネルを採用している[48]。
Microsoft Windowsは1985年、MS-DOSへのアドオンとしてリリースされた。他のOSに依存していたため、Windows 95までのリリースはOSではなくオペレーティング環境とみなされている。その製品ラインは発展して、Windows 9x系となり（32ビット化やプリエンプティブ・マルチタスクといった強化を経て）、最終的に2000年にWindows Meがリリースされた。マイクロソフトはまた、ハイエンド向けにWindows NT のラインも1993年の Windows NT 3.1からスタートさせ、こちらは2000年以降も続いている。
2001年10月にリリースされたWindows XPでWindows 9x系を置換して一般ユーザー向けOSが一新された。Windows NT系のカーネルはWindow ManagerやIPC Managerとクライアント・サーバ型階層型サブシステムモデルを採用しており、ハイブリッドカーネルとみなされている[49]。
汎用マイクロカーネルとしてはカーネギーメロン大学が1985年から1994年まで開発したMachが有名だが、特定用途向けにもいくつかのマイクロカーネルが開発された。L4はマイクロカーネルの性能が悪くないことを実証するために作られた[39]。ここから派生した新たな実装の Fiasco や Pistachio はLinuxをその上で動作させることができる[50][51]。
QNXはマイクロカーネル設計を採用したリアルタイムオペレーティングシステムであり、1980年代初期に開発され、Machよりもはるかに成功している[52]。ソフトウェアが不正作動することが致命的な状況で使われることが多く、スペースシャトルのロボットアームの制御やガラスを精密に磨く機械の制御で使われている。
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
