マイクロカーネル
マイクロカーネル上で任意のOSサービス群を構築しなければならない場合、マイクロカーネルはいくつかの中核機能を提供しなければならない。最小でも以下が含まれる。
アドレス空間を扱う何らかの機構 - メモリ保護に必要
CPU割り当てのための何らかの実行抽象化 - スレッドまたは scheduler activations が典型的
プロセス間通信 - 独立したアドレス空間で動作するサーバ群を呼び出すのに必要
このような最小設計は Per Brinch Hansen の Nucleus とIBMのVM(英語版)のハイパーバイザがさきがけである。そして、リートケの「極小原則」として次のように定式化された。
ある概念をマイクロカーネル内で実現することが許されるのは、それをカーネルの外に移した場合、すなわち競合する実装が可能となることでシステム必須の機能が妨げられる場合だけである。
他のあらゆるものはユーザーモードのプログラムとして実装できるが、デバイスドライバをユーザープログラムとして実装する場合、一部のプロセッサアーキテクチャではI/Oハードウェアにアクセスするための特別な特権を必要とする。
極小原則とも関連しマイクロカーネル設計で重要な観点として機構と方針の分離があり、極小のカーネル上に任意のシステムを構築できるようにするのに必要である。方針をカーネル内で実装すると、ユーザーレベルでは上書きできず、マイクロカーネルの可能性が一般に制限される。ユーザーレベルのサーバで実装された方針はサーバを置換することで(あるいは同様のサービスを提供する複数のサーバからアプリケーションが選択することで)変更できる。
純粋なマイクロカーネルでは、まずカーネル空間で提供される機能を、メモリ空間の仮想化、プロセス制御、プロセス間通信に限定し、割り込みなども全て通信にマップする。その上でファイルシステムやデバイスドライバといった準カーネル機能をそれらのアプリケーションとして実装し、ユーザー空間で動作させる。場合によってはそれらの機能セットをサーバと呼ばれる単位で複数動作させる。
このような形態を持つ事のメリットは、
OS開発効率の向上(機能拡張、デバッグなどを容易に行える)
システム全体を止めずにカーネル以外のOSのアップデートを行うことができる
必要な機能のみを提供するアプリケーションに特化したOSを構築することが容易になる
などである。また一般にマイクロカーネルでは資源の抽象度が高く、マルチプロセッサ対応やネットワーク透過の通信が自然に実装できるため、大規模な資源利用には有利である。
反面あらゆる場所でプロセス間通信を利用する為、機能相互のオーバーヘッドが大きく、モノリシックカーネルと同等の機能を実装した場合、数パーセントから数倍のロスが出る場合がある。特にコンテキストスイッチのコストを避けるため、必要な機能をカーネル空間に移し、見た目上モノリシックカーネルのように動作させる場合もある(co-location)。