カーネル（オペレーティング システム）

カーネルは、コンピュータのオペレーティングシステムの中核にあるコンピュータプログラムであり、システム内のすべてのものを常に完全に制御します。カーネルは、異なるプロセス間の競合を防止および緩和する役割も担っています。^{[1]カーネルは、オペレーティングシステムコードのうち、常に}メモリに常駐する部分であり^[2]、ハードウェアコンポーネントとソフトウェアコンポーネント間の相互作用を容易にします。完全なカーネルは、デバイスドライバーを介してすべてのハードウェアリソース（I/O、メモリ、暗号化など）を制御し、そのようなリソースに関するプロセス間の競合を調停し、CPUとキャッシュの使用、ファイルシステム、ネットワークソケットなどの共通リソースの使用を最適化します。ほとんどのシステムでは、カーネルは起動時に読み込まれる最初のプログラムの1つです（ブートローダーの後）。カーネルは、起動の残りの部分に加えて、メモリ、周辺機器、ソフトウェアからの入出力（I/O）要求を処理し、それらを中央処理装置のデータ処理命令に変換します。

カーネルの重要なコードは通常、メモリの別の領域にロードされ、アプリケーションソフトウェアやオペレーティングシステムのそれほど重要でない他の部分からのアクセスから保護されています。カーネルは、プロセスの実行、ハードディスクなどのハードウェアデバイスの管理、割り込みの処理などのタスクを、この保護されたカーネル空間で実行します。対照的に、ブラウザ、ワードプロセッサ、オーディオプレーヤーやビデオプレーヤーなどのアプリケーションプログラムは、メモリの別の領域であるユーザー空間を使用します。この分離により、ユーザーデータとカーネルデータが互いに干渉して不安定性や速度低下を引き起こすことが防止され、^{[1]誤動作したアプリケーションが他のアプリケーションに影響を与えたり、オペレーティングシステム全体がクラッシュしたりすることが防止されます。カーネルがアプリケーション}アドレス空間に含まれているシステムでも、メモリ保護を使用して、許可されていないアプリケーションがカーネルを変更するのを防ぎます。

カーネルのインターフェースは、低レベルの 抽象化レイヤーです。プロセスがカーネルからサービスを要求する場合、通常はラッパー関数を介してシステムコールを呼び出す必要があります。

カーネルアーキテクチャの設計には様々なものがあります。モノリシックカーネルは、主に速度のため、 CPUがスーパーバイザモードで実行され、単一のアドレス空間で完全に実行されます。マイクロカーネルは、主に回復力とモジュール性のため、ユーザープロセスと同様に、ほとんどのサービスをユーザー空間で実行しますが、すべてではありません。^{[3] MINIX} 3はマイクロカーネル設計の注目すべき例です。Linuxカーネルは、実行時に ロード可能なカーネルモジュールを挿入および削除できるため、モノリシックかつモジュール化されています。

コンピュータ システムの中心的なコンポーネントであるカーネルは、プログラムの実行を担当します。カーネルは、実行中の多数のプログラムのうちどれをプロセッサに割り当てるかをいつでも決定する役割を担います。

ランダム アクセス メモリ(RAM) は、プログラム命令とデータの両方を保存するために使用されます。^[a]通常、プログラムを実行するには、両方がメモリ内に存在している必要があります。多くの場合、複数のプログラムがメモリにアクセスし、コンピューターで使用可能なメモリよりも多くのメモリを要求します。カーネルは、各プロセスが使用できるメモリを決定し、十分なメモリがない場合にどうするかを決定します。

I/O デバイスには、キーボード、マウス、ディスク ドライブ、プリンター、 USBデバイス、ネットワーク アダプター、ディスプレイ デバイスなどの周辺機器が含まれますが、これらに限定されません。カーネルは、アプリケーションがこれらのデバイスを使用するための便利な方法を提供します。これらのデバイスは通常、カーネルによって抽象化されるため、アプリケーションは実装の詳細を知る必要がありません。

リソース管理で必要な主要な側面は、実行ドメイン（アドレス空間）の定義と、ドメイン内のリソースへのアクセスを仲介するために使用される保護メカニズムです。 ^{[5]カーネルは、}同期とプロセス間通信（IPC）の方法も提供します。これらの実装はカーネル自体の中にある場合もあれば、カーネルが実行中の他のプロセスに依存する場合もあります。カーネルは、互いが提供する機能へのアクセスを提供するためにIPCを提供する必要がありますが、カーネルは実行中のプログラムにこれらの機能へのアクセスを要求する方法も提供する必要があります。カーネルは、プロセス間またはスレッド間のコンテキスト切り替えも担当します。

カーネルはシステムのメモリに完全にアクセスでき、プロセスが必要に応じてこのメモリに安全にアクセスできるようにする必要があります。多くの場合、これを行うための最初のステップは仮想アドレス指定であり、通常はページングやセグメンテーションによって実現されます。仮想アドレス指定により、カーネルは特定の物理アドレスを別のアドレス (仮想アドレス) として表示できます。仮想アドレス空間はプロセスごとに異なる場合があります。つまり、あるプロセスが特定の (仮想) アドレスでアクセスするメモリは、別のプロセスが同じアドレスでアクセスするメモリとは異なる場合があります。これにより、すべてのプログラムは (カーネルを除いて) 実行されている唯一のプログラムであるかのように動作し、アプリケーションが互いにクラッシュするのを防ぎます。^[6]

多くのシステムでは、プログラムの仮想アドレスは、現在メモリ内に存在しないデータを参照する場合があります。仮想アドレス指定によって提供される間接層により、オペレーティング システムは、本来はメイン メモリ ( RAM )内に残しておく必要があるデータを、ハード ドライブなどの他のデータ ストアに格納できます。その結果、オペレーティング システムは、システムが物理的に使用できるメモリよりも多くのメモリをプログラムが使用できるようにします。プログラムが現在 RAM 内に存在しないデータを必要とする場合、CPU はカーネルにその旨を通知し、カーネルはこれに応答して、非アクティブなメモリ ブロックの内容をディスクに書き込み (必要な場合)、プログラムが要求したデータで置き換えます。その後、プログラムは停止した時点から再開できます。この方式は一般にデマンド ページングと呼ばれます。

仮想アドレス指定では、2 つの分離された領域に仮想メモリ パーティションを作成することもできます。1 つはカーネル用 (カーネル空間)、もう 1 つはアプリケーション用 (ユーザー空間) です。プロセッサはアプリケーションによるカーネル メモリのアドレス指定を許可しないため、実行中のカーネルにアプリケーションが損傷を与えるのを防ぎます。このメモリ空間の基本的なパーティションは、実際の汎用カーネルの現在の設計に大きく貢献しており、このようなシステムではほぼ普遍的ですが、一部の研究用カーネル ( Singularityなど) では別のアプローチが採用されています。

プロセスが有用な機能を実行するには、コンピュータに接続された周辺機器にアクセスする必要があります。周辺機器は、デバイス ドライバを介してカーネルによって制御されます。デバイス ドライバは、OS に代わってハードウェア デバイスをカプセル化し、監視および制御するコンピュータ プログラムです (ハードウェア/ソフトウェア インターフェイス (HSI) 経由)。デバイス ドライバは、オペレーティング システムに API、手順、および特定のハードウェアの制御方法と通信方法に関する情報を提供します。デバイス ドライバは、すべての OS とそのアプリケーションにとって重要かつ不可欠な依存関係です。ドライバの設計目標は抽象化です。ドライバの機能は、OS が義務付けた抽象関数呼び出し (プログラミング呼び出し) をデバイス固有の呼び出しに変換することです。理論上、デバイスは適切なドライバを使用すれば正常に動作するはずです。デバイス ドライバは、ビデオ カード、サウンド カード、プリンタ、スキャナ、モデム、ネットワーク カードなどに使用されます。

ハードウェア レベルでは、デバイス ドライバーの一般的な抽象化には次のものが含まれます。

• 直接インターフェース
• 高レベルインターフェース（ビデオBIOS）の使用
• 低レベルのデバイス ドライバー (ディスク ドライバーを使用するファイル ドライバー) の使用
• ハードウェアで作業をシミュレートしながら、まったく異なることをする

ソフトウェア レベルでは、デバイス ドライバーの抽象化には次のものが含まれます。

• オペレーティングシステムがハードウェアリソースに直接アクセスできるようにする
• プリミティブのみを実装する
• TWAINなどの非ドライバソフトウェア用のインターフェースの実装
• 言語の実装（多くの場合、 PostScriptなどの高級言語）

たとえば、ユーザーに画面上に何かを表示するために、アプリケーションはカーネルに要求を行い、カーネルはその要求をディスプレイドライバに転送し、ディスプレイドライバが実際に文字/ピクセルをプロットする責任を負います。^[6]

カーネルは、利用可能なデバイスのリストを維持する必要があります。このリストは、事前にわかっている場合 (たとえば、利用可能なハードウェアが変更されるとカーネルが書き換えられる組み込みシステムの場合)、ユーザーによって構成される場合 (古い PC や個人使用向けに設計されていないシステムの場合が一般的)、または実行時にオペレーティング システムによって検出される場合 (通常、プラグ アンド プレイと呼ばれます) があります。プラグ アンド プレイ システムでは、デバイス マネージャーは、最初にPCI ( Peripheral Component Interconnect ) や USB ( Universal Serial Bus )などのさまざまな周辺バスをスキャンして、インストールされているデバイスを検出し、次に適切なドライバーを検索します。

デバイス管理はOS固有のトピックであるため、これらのドライバーはカーネル設計の種類ごとに異なる方法で処理されますが、いずれの場合も、ドライバーが何らかのポートまたはメモリ位置を介してデバイスに物理的にアクセスできるように、カーネルはI/O を提供する必要があります。デバイス管理システムを設計する際には、重要な決定を行う必要があります。一部の設計では、アクセスにコンテキスト スイッチが含まれる場合があり、操作が CPU を集中的に使用し、パフォーマンスのオーバーヘッドが著しく高くなる可能性があります。^{[引用が必要]}

コンピューティングにおいて、システム コールとは、プロセスが通常は実行権限を持たないサービスをオペレーティング システムのカーネルから要求する方法です。システム コールは、プロセスとオペレーティング システム間のインターフェイスを提供します。システムと対話するほとんどの操作には、ユーザー レベルのプロセスでは利用できない権限が必要です。たとえば、システムに存在するデバイスで実行される I/O や、他のプロセスとのあらゆる形式の通信には、システム コールを使用する必要があります。

システム コールは、アプリケーション プログラムがオペレーティング システムにサービスを要求するために使用するメカニズムです。システム コールでは、プロセッサのモードを変更するマシン コード命令を使用します。たとえば、スーパーバイザー モードから保護モードへの変更です。このモードでは、オペレーティング システムはハードウェア デバイスやメモリ管理ユニットへのアクセスなどのアクションを実行します。通常、オペレーティング システムは、オペレーティング システムと通常のユーザー プログラムの間にあるライブラリを提供します。通常、これはGlibcや Windows APIなどのC ライブラリです。ライブラリは、カーネルに情報を渡したり、スーパーバイザー モードに切り替えたりする低レベルの詳細を処理します。システム コールには、close、open、read、wait、write があります。

実際に有用な作業を実行するには、プロセスはカーネルが提供するサービスにアクセスできる必要があります。これはカーネルごとに異なる方法で実装されていますが、ほとんどのカーネルはCライブラリまたはAPIを提供し、関連するカーネル関数を呼び出します。^[7]

カーネル関数を呼び出す方法はカーネルによって異なります。メモリ分離が使用されている場合、ユーザー プロセスがカーネルを直接呼び出すことは不可能です。これは、プロセッサのアクセス制御ルールに違反することになるからです。いくつかの可能性は次のとおりです。

• ソフトウェアでシミュレートされた割り込みを使用する。この方法はほとんどのハードウェアで使用できるため、非常に一般的です。
• コール ゲートの使用。コール ゲートは、プロセッサが認識している場所のカーネル メモリ内のリストにカーネルによって保存される特別なアドレスです。プロセッサがそのアドレスへの呼び出しを検出すると、アクセス違反を起こさずにターゲットの場所にリダイレクトします。これにはハードウェア サポートが必要ですが、そのためのハードウェアは非常に一般的です。
• 特別なシステム コール命令を使用する。この手法には特別なハードウェア サポートが必要であり、一般的なアーキテクチャ (特にx86 ) にはそれがない場合があります。ただし、x86 プロセッサの最新モデルにはシステム コール命令が追加されており、PC 用の一部のオペレーティング システムでは、利用可能な場合にそれを使用します。
• メモリベースのキューの使用。大量のリクエストを行うが、それぞれの結果を待つ必要がないアプリケーションは、カーネルがリクエストを見つけるために定期的にスキャンするメモリ領域にリクエストの詳細を追加できます。

カーネルの設計において重要な考慮事項は、障害（フォールトトレランス）からの保護と悪意のある動作（セキュリティ）からの保護に対するサポートです。通常、これら2つの側面は明確に区別されておらず、カーネル設計でこの区別を採用すると、保護のための階層構造が拒否されます。^[5]

カーネルが提供するメカニズムやポリシーは、静的（コンパイル時に強制）か動的（実行時に強制）、プリエンプティブか事後検出か、満たす保護原則（例：Denning ^{[8] [9]}）、ハードウェアでサポートされているか言語ベースか、オープンメカニズムかバインディングポリシーか、など、いくつかの基準に従って分類できます。

階層的保護ドメイン^[10]のサポートは、通常CPUモードを使用して実装されます。

多くのカーネルは、「機能」の実装を提供します。つまり、ユーザー コードに提供されるオブジェクトで、カーネルによって管理される基礎オブジェクトへの限定されたアクセスを許可します。一般的な例としては、ファイル処理があります。ファイルとは、永続的なストレージ デバイスに保存されている情報の表現です。カーネルは、読み取り、書き込み、削除、実行など、さまざまな操作を実行できますが、ユーザー レベルのアプリケーションは、これらの操作の一部しか実行できない場合があります (たとえば、ファイルの読み取りのみが許可される場合があります)。一般的な実装では、カーネルがアプリケーションにオブジェクト (通常は「ファイル ハンドル」と呼ばれる) を提供し、アプリケーションはそのオブジェクトに対して操作を呼び出すことができます。カーネルは、操作が要求された時点でその有効性をチェックします。このようなシステムは、カーネルが管理するすべてのオブジェクト、さらには他のユーザー アプリケーションによって提供されるオブジェクトをカバーするように拡張できます。

ハードウェアによるケイパビリティのサポートを効率的かつシンプルに提供する方法の一つは、メモリ管理ユニット（MMU）にメモリアクセスのたびにアクセス権をチェックする責任を委任することであり、このメカニズムはケイパビリティベースアドレッシングと呼ばれます。^[11]ほとんどの商用コンピュータアーキテクチャには、このようなMMUによるケイパビリティのサポートがありません。

代替アプローチは、一般的にサポートされている階層型ドメインを使用して機能をシミュレートすることです。このアプローチでは、保護された各オブジェクトは、アプリケーションがアクセスできないアドレス空間に存在する必要があります。カーネルは、そのようなメモリ内に機能のリストも保持します。アプリケーションが機能によって保護されたオブジェクトにアクセスする必要がある場合、システムコールを実行し、カーネルはアプリケーションの機能が要求されたアクションを実行する許可を与えるかどうかを確認し、許可されている場合は、アクセスを実行します (直接、または別のユーザーレベルプロセスに要求を委任することによって)。アドレス空間の切り替えによるパフォーマンスコストにより、オブジェクト間の複雑な相互作用があるシステムではこのアプローチの実用性が制限されますが、現在のオペレーティングシステムでは、頻繁にアクセスされないオブジェクトや、迅速に実行することが期待されないオブジェクトに使用されています。^{[12] [13]}

ファームウェアが保護メカニズムをサポートしていない場合は、ページテーブルを操作して機能をシミュレートするなど、より高いレベルで保護をシミュレートすることは可能ですが、パフォーマンスに影響があります。^[14]ただし、言語ベースの保護を使用することを選択したシステムでは、ハードウェアサポートの欠如は問題にならない可能性があります。^[15]

カーネル設計における重要な決定は、セキュリティメカニズムとポリシーを実装する抽象化レベルの選択である。カーネルセキュリティメカニズムは、より高いレベルでのセキュリティをサポートする上で重要な役割を果たしている。^{[11] [16] [17] [18] [19]}

1 つのアプローチは、フォールト トレランス (上記参照) にファームウェアとカーネルのサポートを使用し、その上に悪意のある動作に対するセキュリティ ポリシーを構築し (必要に応じて暗号化メカニズムなどの機能を追加)、一部の責任をコンパイラに委任することです。セキュリティ ポリシーの適用をコンパイラやアプリケーション レベルに委任するアプローチは、多くの場合、言語ベースのセキュリティと呼ばれます。

現在主流のオペレーティングシステムには多くの重要なセキュリティメカニズムが欠けており、アプリケーション抽象化レベルで適切なセキュリティポリシーを実装することが妨げられています。^[16]実際、コンピュータセキュリティにおける一般的な誤解は、カーネルのサポートに関係なく、アプリケーションに任意のセキュリティポリシーを実装できるというものです。^[16]

Mars Research Groupの開発者によると、分離の欠如はカーネルのセキュリティを損なう主な要因の1つです。^[20]彼らは、主にLinuxカーネルの保護のためにドライバー分離フレームワークを提案しています。^{[21] [22]}

今日の典型的なコンピュータシステムでは、どのプログラムがどのデータにアクセスできるかについて、ハードウェアによって強制されるルールが使用されています。プロセッサは実行を監視し、カーネルメモリに書き込もうとするユーザープロセスなど、ルールに違反するプログラムを停止します。機能のサポートがないシステムでは、プロセスは別々のアドレス空間を使用して互いに分離されます。^[23]ユーザープロセスからカーネルへの呼び出しは、上記のシステムコール方法のいずれかを使用することを要求することで規制されています。

代替アプローチは、言語ベースの保護を使用することです。言語ベースの保護システムでは、カーネルは信頼できる言語コンパイラによって生成されたコードのみを実行できるようにします。これにより、プログラマがセキュリティ要件に違反するようなことを指示することが不可能になるように言語を設計できます。^[15]

このアプローチの利点は次のとおりです。

• 個別のアドレス空間は必要ありません。アドレス空間の切り替えは、大きなオーバーヘッドを引き起こす低速な操作であり、現在のオペレーティング システムでは不要な切り替えを防ぐために多くの最適化作業が行われています。言語ベースの保護システムでは、すべてのコードが同じアドレス空間で安全に動作できるため、切り替えはまったく不要です。
• 柔軟性。プログラミング言語で表現できるように設計できる保護スキームは、この方法を使用して実装できます。保護スキームの変更 (階層型システムから機能ベースのシステムへの変更など) には、新しいハードウェアは必要ありません。

デメリットは次のとおりです:

• アプリケーションの起動時間が長くなります。アプリケーションの起動時に、正しいコンパイラによってコンパイルされていることを確認する必要があります。そうでない場合は、ソース コードまたはバイトコードからの再コンパイルが必要になる場合があります。
• 柔軟性のない型システム。従来のシステムでは、アプリケーションは型安全でない操作を頻繁に実行します。このような操作は言語ベースの保護システムでは許可されないため、アプリケーションを書き直す必要があり、場合によってはパフォーマンスが低下する可能性があります。

言語ベースの保護を備えたシステムの例としては、 JXやMicrosoftのSingularityなどがあります。

エドガー・ダイクストラは、論理的な観点から、バイナリセマフォ上で動作するアトミック ロックおよびロック解除操作は、プロセス協調のあらゆる機能を表現するのに十分なプリミティブであることを証明しました。^[24]しかし、このアプローチは一般的に安全性と効率性の点で欠けていると考えられており、メッセージパッシングアプローチはより柔軟です。^{[25]他の多くのアプローチ（低レベルまたは高レベル）も利用可能であり、多くの最新のカーネルは}共有メモリやリモートプロシージャコール などのシステムをサポートしています。

I/Oデバイスが他のプロセスと一様に並列に協調動作するプロセスとして扱われるカーネルのアイデアは、最初にブリンチ・ハンセンによって提案され実装された（1967年にも同様のアイデアが提案されていた^{[26] [27] ）。ハンセンの説明では、「共通」プロセスは}内部プロセスと呼ばれ、I/Oデバイスは外部プロセスと呼ばれている。^[25]

物理メモリと同様に、アプリケーションがコントローラのポートやレジスタに直接アクセスできるようにすると、コントローラが誤動作したり、システムがクラッシュしたりする可能性があります。そのため、デバイスの複雑さによっては、一部のデバイスは驚くほどプログラムが複雑になり、複数の異なるコントローラを使用する場合があります。このため、デバイスを管理するには、より抽象的なインターフェイスを提供することが重要です。このインターフェイスは通常、デバイス ドライバまたはハードウェア抽象化レイヤーによって行われます。多くの場合、アプリケーションはこれらのデバイスにアクセスする必要があります。カーネルは、何らかの方法でシステムにクエリを実行して、これらのデバイスのリストを維持する必要があります。これは、BIOS またはさまざまなシステム バス (PCI/PCIE、USB など) のいずれかを介して行うことができます。ビデオ ドライバの例を使用すると、アプリケーションが文字の表示などのデバイス操作を要求すると、カーネルはこの要求を現在アクティブなビデオ ドライバに送信する必要があります。ビデオ ドライバは、この要求を実行する必要があります。これは、プロセス間通信(IPC) の例です。

上記のタスクと機能は、設計と実装がそれぞれ異なるさまざまな方法で提供できます。

メカニズムとポリシーの分離の原則は、マイクロカーネルとモノリシックカーネルの哲学の本質的な違いです。^{[28] [29]}ここで、メカニズムは多くの異なるポリシーの実装を可能にするサポートであり、ポリシーは特定の「動作モード」です。例:

• メカニズム:ユーザーのログイン試行は認可サーバーにルーティングされます
• ポリシー:認証サーバーは、データベースに保存されているパスワードと照合されるパスワードを必要とします。

メカニズムとポリシーが分離されているため、たとえばセキュリティ トークンの使用を要求するようにポリシーを簡単に変更できます。

最小限のマイクロカーネルにはごく基本的なポリシーのみが含まれ、^[29]そのメカニズムにより、カーネル上で実行されているもの（オペレーティングシステムの残りの部分と他のアプリケーション）がどのポリシーを採用するかを決定できます（メモリ管理、高レベルのプロセススケジューリング、ファイルシステム管理など）。^{[5] [25]}一方、モノリシックカーネルには多くのポリシーが含まれる傾向があり、そのためシステムの残りの部分がそれらに依存することが制限されます。

Per Brinch Hansen はメカニズムとポリシーの分離を支持する議論を展開した。^{[5] [25]}この分離が適切に行われなかったことが、既存のオペレーティングシステムに実質的な革新が見られなかった主な原因の 1 つであり^[5] 、これはコンピュータアーキテクチャで一般的な問題である。^{[30] [31] [32]}モノリシック設計は、従来の商用システムで一般的な「カーネルモード」/「ユーザーモード」の保護アーキテクチャアプローチ (技術的には階層的保護ドメインと呼ばれる) によってもたらされた。^[33]実際、保護を必要とするすべてのモジュールは、カーネルに含まれることが望ましい。^[33]モノリシック設計と「特権モード」の間のこのつながりは、メカニズムとポリシーの分離という重要な問題に結びつく。^[5]実際、「特権モード」アーキテクチャアプローチは、保護メカニズムとセキュリティポリシーを融合するが、主要な代替アーキテクチャアプローチである機能ベースアドレッシングは、この 2 つを明確に区別し、自然にマイクロカーネル設計につながる^[5] ( 「保護とセキュリティの分離」を参照)。

モノリシックカーネルはすべてのコードを同じアドレス空間（カーネル空間）で実行するのに対し、マイクロカーネルはサービスの大部分をユーザー空間で実行し、コードベースの保守性とモジュール性を向上させることを目指しています。^[4]ほとんどのカーネルはこれらのカテゴリのいずれかに正確には当てはまらず、むしろこれら2つの設計の中間に位置します。これらはハイブリッドカーネルと呼ばれます。ナノカーネルやエクソカーネルなどのよりエキゾチックな設計もありますが、実稼働システムで使用されることはほとんどありません。たとえば、 Xenハイパーバイザーはエクソカーネルです。

モノリシックカーネルでは、すべての OS サービスがメインカーネルスレッドとともに実行されるため、同じメモリ領域に常駐します。このアプローチは、豊富で強力なハードウェアアクセスを提供します。UNIX開発者のKen Thompson は、「[彼の] 意見では、モノリシックカーネルを実装する方が簡単です」と述べています。^[34]モノリシックカーネルの主な欠点は、システムコンポーネント間の依存関係 (デバイスドライバーのバグによりシステム全体がクラッシュする可能性がある) と、大規模なカーネルの保守が非常に困難になる可能性があることです。Thompson は、「[モノリシックカーネル] は、変更されるとすぐに混乱に陥りやすくなります」とも述べています。^[34]

モノリシック カーネルは、従来 Unix 系オペレーティング システムで使用されており、オペレーティング システムのコア機能とデバイス ドライバーがすべて含まれています。モノリシック カーネルは、カーネル関連のタスクを実行するために必要なすべてのコードを含む単一のプログラムです。ほとんどのプログラムがアクセスするがライブラリに配置できないすべての部分は、カーネル スペースにあります。デバイス ドライバー、スケジューラー、メモリ処理、ファイル システム、ネットワーク スタックなどです。アプリケーションには多くのシステム コールが提供されており、これらすべてのサービスにアクセスできます。モノリシック カーネルは、最初は必要のないサブシステムがロードされますが、ハードウェア専用に設計されたカーネルと同等かそれ以上の速度に調整できます。ただし、一般的な意味では、より関連性が高いと言えます。

Linux カーネル、FreeBSDカーネル、AIXカーネル、HP-UXカーネル、Solarisカーネルなど、Unix 系オペレーティング システムに分類される最新のモノリシック カーネルは、ロード可能なカーネル モジュールをサポートしています。これにより、実行時にモジュールをカーネルにロードできるため、必要に応じてカーネルの機能を簡単に拡張できると同時に、カーネル空間で実行されるコードの量を最小限に抑えることができます。

モノリシック カーネルでの作業のほとんどは、システム コールを介して行われます。これらは通常、表形式の構造で保持されるインターフェイスであり、ディスク操作などのカーネル内のサブシステムにアクセスします。基本的に、呼び出しはプログラム内で行われ、要求のチェック済みコピーがシステム コールを介して渡されます。したがって、移動距離はまったくありません。モノリシック Linux カーネルは、モジュールを動的にロードできるだけでなく、カスタマイズが容易なため、非常に小さくすることができます。実際、多数のユーティリティやその他のプログラムを 1 枚のフロッピー ディスクに収めることができ、それでも完全に機能するオペレーティング システムを提供できるほど小さいバージョンもあります (最も人気のあるものの 1 つはmuLinuxです)。カーネルを小型化できるこの能力は、組み込みシステムでのLinuxの使用も急速に増加することにつながっています。

これらのタイプのカーネルは、オペレーティング システムのコア機能と、実行時にモジュールをロードする機能を備えたデバイス ドライバーで構成されています。これらは、基盤となるハードウェアの豊富で強力な抽象化を提供します。これらは、単純なハードウェア抽象化の小さなセットを提供し、サーバーと呼ばれるアプリケーションを使用してより多くの機能を提供します。この特定のアプローチは、ハードウェア上の高レベルの仮想インターフェイスを定義し、一連のシステム コールを使用して、スーパーバイザー モードで実行される複数のモジュールでプロセス管理、同時実行、メモリ管理などのオペレーティング システム サービスを実装します。この設計には、いくつかの欠陥と制限があります。

• カーネルでのコーディングは、一般的なライブラリ (フル機能のlibcなど) を使用できないことや、gdbなどのソース レベルのデバッガを使用する必要があることなどから、難しい場合があります。コンピュータの再起動が必要になることもよくあります。これは、開発者にとっての利便性の問題だけではありません。デバッグが難しくなり、困難さが増すにつれて、コードに「バグ」が多くなる可能性が高くなります。
• カーネルの一部にバグがあると、強い副作用が生じます。カーネル内のすべての関数がすべての権限を持っているため、1 つの関数にバグがあると、カーネルのまったく関係のない別の部分や実行中のプログラムのデータ構造が破損する可能性があります。
• カーネルは多くの場合非常に大きくなり、保守が困難になります。
• これらの操作を処理するモジュールが全体から分離されている場合でも、コードの統合は緊密であり、正しく実行するのは困難です。
• モジュールは同じアドレス空間で実行されるため、バグによってシステム全体がダウンする可能性があります。

マイクロカーネル (μK または uK とも略される) は、システムの機能を従来の「カーネル」から「最小限の」カーネルを介して通信する一連の「サーバー」に移し、「システム空間」をできるだけ少なくし、「ユーザー空間」をできるだけ多くする、オペレーティングシステム設計のアプローチを表す用語です。特定のプラットフォームまたはデバイス用に設計されたマイクロカーネルには、動作に必要なものだけが含まれます。マイクロカーネル アプローチは、一連のプリミティブまたはシステム コールを使用して、メモリ管理、マルチタスク、プロセス間通信などの最小限の OS サービスを実装するハードウェア上の単純な抽象化を定義します。ネットワークなど、カーネルによって通常提供されるサービスを含むその他のサービスは、サーバーと呼ばれるユーザー空間プログラムで実装されます。マイクロカーネルはモノリシック カーネルよりも保守が容易ですが、システム コールとコンテキスト スイッチの数が多いと、単純な関数呼び出しよりもオーバーヘッドが多く発生するため、システムの速度が低下する可能性があります。

カーネル空間には、特権モードであることが本当に必要な部分、つまり IPC (プロセス間通信)、基本スケジューラ、またはスケジューリング プリミティブ、基本メモリ処理、基本 I/O プリミティブだけがあります。現在、多くの重要な部分はユーザー空間で実行されています。完全なスケジューラ、メモリ処理、ファイル システム、およびネットワーク スタックです。マイクロカーネルは、従来の「モノリシック」カーネル設計に対する反応として発明されました。この設計では、すべてのシステム機能が、プロセッサの特別な「システム」モードで実行される 1 つの静的プログラムにまとめられていました。マイクロカーネルでは、ハードウェアの一部 (必ずしもすべてではありません) にアクセスしたり、メモリを管理したり、プロセス間でメッセージ パッシングを調整したりするなど、最も基本的なタスクのみが実行されます。マイクロカーネルを使用するシステムには、QNX や HURD などがあります。QNX や Hurd の場合、ユーザーセッションは、システム自体のスナップショット全体、またはいわゆるビューになります。マイクロカーネル アーキテクチャの本質は、その利点のいくつかを示しています。

• メンテナンスが簡単
• パッチは別のインスタンスでテストし、その後、本番インスタンスに引き継ぐためにスワップインすることができます。
• 開発時間が短縮され、カーネルを再起動せずに新しいソフトウェアをテストできます。
• 一般的に、より永続的であるため、1 つのインスタンスがおかしくなった場合、それを動作中のミラーで置き換えることがしばしば可能です。

ほとんどのマイクロカーネルは、あるサーバーから別のサーバーへのリクエストを処理するためにメッセージ パッシングシステムを使用します。メッセージ パッシング システムは、通常、マイクロカーネルでポートベースで動作します。たとえば、メモリの増設リクエストが送信されると、マイクロカーネルでポートが開かれ、リクエストが送信されます。マイクロカーネル内に入ると、手順はシステム コールに似ています。その理由は、システム アーキテクチャにモジュール性をもたらし、システムのクリーン化、デバッグや動的な変更の容易化、ユーザーのニーズに合わせたカスタマイズ、パフォーマンスの向上につながるからです。マイクロカーネルは、GNU Hurd、MINIX、MkLinux、QNX、Redox OSなどのオペレーティング システムの一部です。マイクロカーネル自体は非常に小さいですが、必要な補助コードをすべて組み合わせると、実際にはモノリシック カーネルよりも大きくなることがよくあります。モノリシック カーネルの支持者は、オペレーティング システムの大部分がハードウェアと直接やり取りしないマイクロカーネル システムの 2 層構造により、システム効率の面で少なからずコストがかかると指摘しています。これらのタイプのカーネルは通常、メモリ アドレス空間の定義、プロセス間通信 (IPC)、プロセス管理などの最小限のサービスのみを提供します。ハードウェア プロセスの実行などのその他の機能は、マイクロカーネルによって直接処理されません。マイクロカーネルの支持者は、これらのモノリシック カーネルには、カーネルのエラーによってシステム全体がクラッシュする可能性があるという欠点があると指摘しています。ただし、マイクロカーネルでは、カーネル プロセスがクラッシュしても、エラーの原因となったサービスを再起動するだけで、システム全体のクラッシュを防ぐことができます。

カーネルが提供するその他のサービス、たとえばネットワークなどは、サーバーと呼ばれるユーザー空間プログラムに実装されています。サーバーを使用すると、プログラムを起動および停止するだけでオペレーティング システムを変更できます。たとえば、ネットワークをサポートしていないマシンの場合、ネットワーク サーバーは起動されません。さまざまなアプリケーションとサーバーの間でデータを移動するためにカーネルに出入りするタスクによってオーバーヘッドが発生し、モノリシック カーネルと比較するとマイクロカーネルの効率が悪くなります。

ただし、マイクロカーネルには欠点もあります。いくつか例を挙げます。

• 実行メモリのフットプリントが大きい
• インターフェース用のソフトウェアがさらに必要となり、パフォーマンスが低下する可能性があります。
• メッセージングのバグは、モノリシック カーネルでの 1 回限りのコピーと比べて、実行に長い時間がかかるため、修正が難しくなる可能性があります。
• プロセス管理は一般的に非常に複雑になることがあります。

マイクロカーネルの欠点は、状況に大きく左右されます。たとえば、実行するプロセスがそれほど多くない場合はプロセス管理の複雑さが効果的に軽減されるため、マイクロカーネルは小規模な単一目的の (かつ重要な) システムに適しています。

マイクロカーネルは、オペレーティングシステムの残りの部分を高級言語で書かれた通常のアプリケーションプログラムとして実装し、同じカーネル上で異なるオペレーティングシステムを使用することを可能にします。また、オペレーティングシステムを動的に切り替えたり、複数のオペレーティングシステムを同時にアクティブにしたりすることも可能です。^[25]

コンピュータカーネルが大きくなるにつれて、その信頼できるコンピューティングベースのサイズと脆弱性も大きくなります。また、セキュリティが低下するだけでなく、メモリフットプリントが大きくなるという問題もあります。この問題は、仮想メモリシステムを完成することである程度緩和されますが、すべてのコンピュータアーキテクチャが仮想メモリをサポートしているわけではありません。^[b]カーネルのフットプリントを削減するには、不要なコードを慎重に削除するための大規模な編集を行う必要がありますが、数百万行のコードを含むカーネルの各部分間の相互依存性が明らかでない場合は、非常に困難な場合があります。

1990年代初頭までに、モノリシックカーネルとマイクロカーネルのさまざまな欠点により、モノリシックカーネルは事実上すべてのオペレーティングシステム研究者によって時代遅れと見なされるようになりました。^[要出典]その結果、Linuxをマイクロカーネルではなくモノリシックカーネルとして設計することは、リーナス・トーバルズとアンドリュー・タネンバウムの間の有名な論争の話題となりました。^[35]タネンバウムとトーバルズの論争で提示された議論には、どちらの側にもメリットがあります。

モノリシックカーネルは、すべてのコードを同じアドレス空間（カーネル空間）に配置するように設計されており、一部の開発者は、システムのパフォーマンスを向上させるためにこれが必要であると主張しています。^[36]また、一部の開発者は、モノリシックシステムは適切に記述されていれば非常に効率的であると主張しています。^[36]モノリシックモデルは、通常、メッセージパッシングに基づくマイクロカーネル設計の低速なIPCシステムではなく、共有カーネルメモリを使用することで、より効率的になる傾向があります。 [37 ^{] 。[要出典]}

マイクロカーネルの性能は、1980年代と1990年代初頭の両方で低かった。^{[38] [39]}しかし、これらのマイクロカーネルの性能を経験的に測定した研究では、そのような非効率性の理由を分析しなかった。^[38]このデータの説明は「伝説」に残されており、「カーネルモード」から「ユーザーモード」への切り替え頻度の増加、プロセス間通信頻度の増加、コンテキストスイッチ頻度の増加によるものと想定されていた。^[38]

実際、1995年に推測されたように、マイクロカーネルのパフォーマンスが低い理由は、(1)マイクロカーネルアプローチ全体の実際の非効率性、(2)それらのマイクロカーネルに実装された特定の概念、(3)それらの概念の特定の実装であった可能性があります。したがって、効率的なマイクロカーネルを構築するための解決策が、以前の試みとは異なり、正しい構築技術を適用することであるかどうかは、まだ研究されていませんでした。^[38]

一方、モノリシックカーネル^[33]の設計につながる階層型保護ドメインアーキテクチャでは、異なるレベルの保護間で相互作用が発生するたびに（つまり、プロセスが「ユーザーモード」と「スーパーバイザモード」の両方でデータ構造を操作する必要がある場合）、値によるメッセージのコピーが必要になるため、パフォーマンスに大きな欠点があります。^[40]

ハイブリッドカーネルは、 Microsoft Windows NT 3.1、NT 3.5、NT 3.51、NT 4.0、2000、XP、Vista、7、8、8.1、10 などのほとんどの商用オペレーティングシステムで使用されています。Apple独自のmacOS は、OSF/1のMach カーネル(OSFMK 7.3) ^[41]とFreeBSDのモノリシックカーネルのコードに基づいたXNUと呼ばれるハイブリッドカーネルを使用しています。ハイブリッドカーネルは、パフォーマンスを向上させるためにカーネル空間に追加のコードが含まれていることを除いて、マイクロカーネルに似ています。これらのカーネルは、モノリシックカーネルとマイクロカーネルの両方の利点を取り入れるために一部の開発者によって実装された妥協案を表しています。これらのタイプのカーネルは、モノリシックカーネルのいくつかの特性を備えたマイクロカーネルの拡張です。モノリシックカーネルとは異なり、これらのタイプのカーネルは実行時に単独ではモジュールをロードできません。^{[要引用]これは、従来のマイクロカーネルのパフォーマンスオーバーヘッドを削減するために、一部のサービス (}ネットワークスタックやファイルシステムなど) をカーネル空間で実行しますが、カーネルコード (デバイスドライバーなど) は引き続きユーザー空間でサーバーとして実行することを意味します。

従来モノリシックだったカーネルの多くは、現在では少なくともモジュール機能を追加 (または使用) しています。こうしたカーネルの中で最もよく知られているのは Linux カーネルです。モジュラー カーネルは、基本的に、コア カーネル バイナリに組み込まれた部分、または要求に応じてメモリにロードされるバイナリを持つことができます。コードが汚染されたモジュールは、実行中のカーネルを不安定にする可能性があります。完全に別のメモリ空間にマイクロカーネル用のドライバを作成し、それを「稼働」させる前にテストすることは可能です。カーネル モジュールがロードされると、必要なものを追加することでモノリシック部分のメモリ空間にアクセスします。そのため、汚染の可能性が生じます。モジュラー (または) ハイブリッド カーネルの利点は次のとおりです。

• モジュール内から操作できるドライバーの開発時間が短縮されます。テストのために再起動する必要はありません (カーネルが不安定になっていない場合)。
• 新しいドライバーやサブシステムなどのためにカーネル全体を再コンパイルするのに時間を費やすのではなく、オンデマンド機能を実現します。
• サードパーティのテクノロジーのより迅速な統合 (開発に関連していますが、それ自体にも関連しています)。

モジュールは、一般的に、何らかのモジュール インターフェイスを使用してカーネルと通信します。インターフェイスは一般化されているため (ただし、特定のオペレーティング システムによって異なります)、モジュールを常に使用できるとは限りません。デバイス ドライバーは、モジュール インターフェイスが提供する以上の柔軟性を必要とすることがよくあります。基本的に、これは 2 つのシステム コールであり、モノリシック カーネルでは 1 回だけ実行する必要があった安全性チェックが、2 回実行される場合があります。モジュール アプローチの欠点は次のとおりです。

• 通過するインターフェースが増えると、バグが増加する可能性が高くなります (つまり、セキュリティ ホールが増えることになります)。
• シンボルの違いなどの問題に対処する場合、モジュールの保守は一部の管理者にとって混乱を招く可能性があります。

ナノカーネルは、割り込みコントローラやタイマーなどの最も基本的なサービスも含め、事実上すべてのサービスをデバイスドライバ に委任し、カーネルメモリ要件を従来のマイクロカーネルよりもさらに小さくします。^[42]

エクソカーネルは、まだ実験段階のオペレーティング システム設計アプローチです。他の種類のカーネルとは異なり、エクソカーネルの機能は生のハードウェアの保護と多重化に限定されており、アプリケーションを開発するためのハードウェア抽象化は提供されていません。ハードウェア保護とハードウェア管理を分離することで、アプリケーション開発者は、特定のプログラムごとに利用可能なハードウェアを最も効率的に使用する方法を決定できます。

エクソカーネル自体は非常に小さい。しかし、ライブラリ オペレーティング システム (ユニカーネルも参照) が付属しており、アプリケーション開発者に従来のオペレーティング システムの機能を提供している。つまり、すべてのユーザーがカーネルの残りの部分をほぼゼロから作成することになるが、これは非常にリスクが高く、複雑で、非常に困難な作業である。特に、時間的制約のある実稼働環境では、エクソカーネルが普及しなかったのはそのためである。^[要出典]エクソカーネル ベースのシステムの主な利点は、複数のライブラリ オペレーティング システムを組み込むことができ、それぞれが異なるAPI をエクスポートできることである。たとえば、1 つは高レベルUI開発用、もう 1 つはリアルタイム制御用などである。

マルチカーネルオペレーティングシステムは、マルチコアマシンを独立したコアのネットワークとして扱い、分散システムであるかのように扱います。共有メモリを想定せず、メッセージパッシングとしてプロセス間通信を実装します。^{[43] [44]} Barrelfishはマルチカーネルとして説明された最初のオペレーティングシステムでした。

厳密に言えば、コンピュータを動かすのにオペレーティングシステム（つまりカーネル）は必須ではない。プログラムの作者がハードウェアの抽象化やオペレーティングシステムのサポートなしで作業する意思があれば、プログラムは「ベアメタル」マシンに直接ロードして実行することができる。1950年代から1960年代初頭にかけて、初期のコンピュータのほとんどはこのように動作し、異なるプログラムの実行の合間にリセットされ、再ロードされていた。最終的に、プログラムローダーやデバッガーなどの小さな補助プログラムは、実行の合間にメモリに残されるか、ROMからロードされるようになった。これらが開発されるにつれて、初期のオペレーティングシステムカーネルの基礎が形成された。「ベアメタル」アプローチは、今日でも一部のビデオゲームコンソールや組み込みシステムで使用されているが^[45]、一般に、新しいコンピュータは最新のオペレーティングシステムとカーネルを使用している。

1969年、RC 4000マルチプログラミングシステムは、小さな核の上に「さまざまな目的のオペレーティングシステムを秩序正しく構築できる」というシステム設計哲学を導入しました^[46]。これはマイクロカーネルアプローチと呼ばれるようになりました。

Unixの前の10年間で、コンピュータの能力は飛躍的に向上し、コンピュータオペレータは、人々が自分のマシンで余暇を過ごすための新しい方法を模索するほどでした。この時代における主要な開発の1つは、タイムシェアリングでした。これは、複数のユーザーがコンピュータ時間を少しずつ取得し、各ユーザーが自分の遅いマシンに接続しているように見える速度でした。^[47]

タイムシェアリングシステムの開発は、多くの問題をもたらした。1つは、ユーザー、特にシステムが開発されていた大学のユーザーが、より多くのCPU時間を得るためにシステムをハッキングしたいようだったことだ。このため、1965年にはセキュリティとアクセス制御がMulticsプロジェクトの主要な焦点となった。^[48]もう1つの継続的な問題は、コンピューティングリソースの適切な処理だった。ユーザーはほとんどの時間を端末を見つめて、実際にコンピュータのリソースを使用するのではなく、何を入力すべきかを考えることに費やしており、タイムシェアリングシステムは、これらの期間中にアクティブなユーザーにCPU時間を与えるべきである。最後に、システムは通常、数層の深いメモリ階層を提供し、この高価なリソースを分割することで、仮想メモリシステムが大きく発展した。

Commodore Amigaは 1985 年に発売され、高度なカーネル アーキテクチャを採用した最初の (そして間違いなく最も成功した) ホーム コンピュータの 1 つでした。AmigaOS カーネルの実行コンポーネントであるexec.library は、マイクロカーネル メッセージ パッシング設計を使用していますが、graphics.libraryなど、ハードウェアに直接アクセスできるカーネル コンポーネントもあります。メモリ保護はなく、カーネルはほぼ常にユーザー モードで実行されます。カーネル モードでは特別なアクションのみが実行され、ユーザー モード アプリケーションはオペレーティング システムにカーネル モードでコードを実行するように要求できます。

Unixの設計段階では、プログラマーは計算の目的はデータ変換であると信じていたため、あらゆる高レベルデバイスをファイルとしてモデル化することを決定しました。^[49]

たとえば、プリンタは既知の場所にある「ファイル」として表され、データがファイルにコピーされると、印刷されました。他のシステムでは、同様の機能を提供するために、デバイスをより低いレベルで仮想化する傾向がありました。つまり、デバイスとファイルの両方が、より低いレベルの概念のインスタンスになります。ファイル レベルでシステムを仮想化することで、ユーザーは既存のファイル管理ユーティリティと概念を使用してシステム全体を操作できるようになり、操作が大幅に簡素化されました。同じパラダイムの拡張として、Unix では、一連の小さなプログラムを使用してプログラマーがファイルを操作できます。パイプの概念を使用すると、ユーザーは段階的に操作を完了でき、ファイルを単一目的のツールのチェーンに送り込むことができます。最終結果は同じですが、このように小さなプログラムを使用すると、柔軟性が大幅に向上し、開発と使用が容易になり、ユーザーはチェーンにプログラムを追加または削除することでワークフローを変更できます。

Unixモデルでは、オペレーティングシステムは2つの部分で構成されています。1つ目は、ほとんどの操作を実行するユーティリティプログラムの膨大なコレクションです。2つ目は、プログラムを実行するカーネルです。^{[49] Unixでは、プログラミングの観点から見ると、この2つの違いはかなり薄く、カーネルはスーパーバイザーモード[c]}で実行されるプログラムであり、システムの残りの部分を構成する小さなユーティリティプログラムのプログラムローダーおよびスーパーバイザーとして機能し、これらのプログラムにロックおよびI/Oサービスを提供します。それ以外に、カーネルはユーザー空間にまったく介入しませんでした。

長年にわたりコンピューティング モデルが変化し、Unix がすべてをファイルまたはバイト ストリームとして扱う方法は、以前のように普遍的に適用できなくなりました。端末はファイルまたはバイト ストリームとして扱い、印刷したり読み込んだりできますが、グラフィカル ユーザー インターフェイスの場合は同じことが当てはまらないようです。ネットワークは別の問題を引き起こしました。ネットワーク通信はファイル アクセスに匹敵しますが、低レベルのパケット指向アーキテクチャは、ファイル全体ではなく、データの個別のチャンクを扱います。コンピューターの機能が増大するにつれて、Unix はますますコードで乱雑になりました。これは、Unix カーネルのモジュール性が広範囲に拡張可能であるためでもあります。^[50] 1970 年代や 1980 年代のカーネルには 10 万行のコードがあったかもしれませんが、 LinuxやGNUなどの現代の Unix の後継カーネルには1,300 万行以上のコードがあります。[ ^51]

現代のUnix派生系は、一般的にモジュールロード型のモノリシックカーネルをベースにしている。この例としては、GNUやIBM AIXの多くのディストリビューションに含まれるLinuxカーネルや、FreeBSD、DragonFly BSD、OpenBSD、NetBSD、macOSなどのBerkeley Software Distributionの派生カーネルが挙げられる。これらの選択肢とは別に、アマチュア開発者は活発なオペレーティングシステム開発コミュニティを維持しており、そこには自作の趣味のカーネルが多数存在し、その多くはLinux、FreeBSD、DragonflyBSD、OpenBSD、NetBSDカーネルと多くの機能を共有し、互換性がある。^[52]

Appleは1984年にMacintoshパソコンにバンドルされたクラシックMac OSを初めてリリースした。AppleはMac OS 8.6でナノカーネル設計に移行した。これに対し、現代のmacOS（当初はMac OS Xと呼ばれていた）はDarwinをベースにしており、4.3BSDカーネルとMachカーネルを組み合わせて作成されたXNUと呼ばれるハイブリッドカーネルを使用している。^[53]

Microsoft Windows は、1985 年にMS-DOSのアドオンとして初めてリリースされました。別のオペレーティング システムに依存していたため、Windows 95 より前の Windows の初期リリースはオペレーティング環境(オペレーティング システムと混同しないでください) と見なされていました。この製品ラインは 1980 年代から 1990 年代にかけて進化を続け、Windows 9xシリーズでは 32 ビット アドレッシングとプリエンプティブ マルチタスクが追加されましたが、2000 年のWindows Meのリリースで終了しました。

Microsoft は、非常によく似たインターフェイスを持ちながら、ハイエンド ユーザーやビジネス ユーザー向けのオペレーティング システムであるWindows NTも開発しました。このラインは、1993 年のWindows NT 3.1のリリースから始まり、 2001 年 10 月のWindows XPのリリースで一般ユーザーに導入されました。Windows XP は、Windows 9xをまったく異なる、はるかに洗練されたオペレーティング システムに置き換えました。このラインは、Windows 11に引き継がれています。

Windows NTのカーネルのアーキテクチャは、カーネル自体にウィンドウマネージャやIPCマネージャなどのタスクが含まれており、クライアント/サーバ階層化サブシステムモデルを採用しているため、ハイブリッドカーネルと見なされています。^[54] Windows NTカーネルはMachマイクロカーネルの影響を受けていますが、純粋なマイクロカーネルの基準をすべて満たしているわけではないため 、修正されたマイクロカーネルとして設計されました。

監視プログラムまたは監視プログラムは、通常はオペレーティング システムの一部であるコンピュータ プログラムであり、他のルーチンの実行を制御し、作業スケジュール、入出力操作、エラー アクション、および同様の機能を規制し、データ処理システム内の作業の流れを規制します。

歴史的に、この用語は基本的に、OS/360から始まるIBMのメインフレームオペレーティング システムラインに関連付けられていました。他のオペレーティング システムでは、スーパーバイザーは一般にカーネルと呼ばれます。

1970 年代に、IBM はハードウェアからスーパーバイザ状態をさらに抽象化し、完全な仮想化、つまり、互いに完全に独立して同じマシン上で複数のオペレーティング システムを実行する機能を可能にするハイパーバイザを実現しました。そのため、このような最初のシステムは仮想マシンまたはVMと呼ばれました。

カーネギーメロン大学のリチャード・ラシッドが開発したMachは最もよく知られている汎用マイクロカーネルだが、より具体的な目的を持った他のマイクロカーネルも開発されてきた。L4マイクロカーネルファミリー（主にL3カーネルとL4カーネル）は、マイクロカーネルが必ずしも遅いわけではないことを実証するために作られた。^[55] FiascoやPistachioなどの新しい実装では、Linuxを他のL4プロセスと別のアドレス空間で実行することができる。^{[56] [57]}

さらに、QNXは主に組み込みシステムで使用されるマイクロカーネルであり、^[58]オープンソースソフトウェアの MINIXは、もともと教育目的で作成されましたが、現在は信頼性が高く自己修復機能を備えたマイクロカーネルOSであることに重点を置いています。

• オペレーティングシステムカーネルの比較
• プロセス間通信
• オペレーティング·システム
• 仮想メモリ

• Andrew S. Tanenbaum、Albert S. Woodhull、「オペレーティングシステム：設計と実装（第3版）」
• Andrew S. Tanenbaum、Herbert Bos、Modern Operating Systems（第 4 版） ;
• Daniel P. Bovet、Marco Cesati、「Linux カーネルの理解 (第 3 版)」
• David A. Patterson、John L. Hennessy、『コンピュータの構成と設計（第6版）』、Morgan Kaufmann （ISBN 978-0-12-820109-1）  ;
• BS Chalk、AT Carter、RW Hind、「コンピュータの構成とアーキテクチャ：入門（第2版）」、Palgrave Macmillan（ISBN 978-1-4039-0164-4）。 

• 最も人気のあるオペレーティングシステムカーネルの詳細な比較