ハイブリッドカーネルは本質的にモノリシックカーネル手法とマイクロカーネルシステムの間の妥協案である。マイクロカーネルの性能オーバヘッドを削減するため一部のサービス（通信プロトコルスタックやファイルシステム）をカーネル空間で動作させるが、一部のカーネルコード（デバイスドライバなど）はサーバとしてユーザ空間で実行する。 ナノカーネルは全てのサービスをデバイスドライバとして分離する。これには例えば最も基本的な割り込みコントローラやタイマーの制御も含まれる。これによりカーネルメモリはマイクロカーネルよりもさらに小さくなる。 Exokernel はハードウェアを為替 モデルに抽象化しないカーネルである。Exokernelは物理ハードウェア資源（プロセッサ時間、メモリページ、ディスクブロック）をプログラムに割り当てる。Exokernel上で動作するプログラムは既知のOSの抽象化を実現する「Library Operating System」をリンクして使用したり、アプリケーション固有の抽象化を行って性能を最適化することができる。 上述した分類に当てはまらないカーネルの設計や実装もある。AmigaOSのカーネル Exec はマイクロカーネル風である。Unununiumはカーネルを持たないOSである[9]。 厳密に言えば、オペレーティングシステム（とカーネル）はコンピュータを動作させるのに必須ではない。プログラムはマシン上に直接ロードされ実行されることも可能であり、そのようなプログラムはOSのサービスや抽象化なしで記述しなければならない。多くの初期のコンピュータではそのような手法が一般的であり、プログラムを入れ替えるときにリセットとリロードが必要だった。その後、プログラムローダーやデバッガといった補助的な小さなプログラムがメモリに常駐したり、ROMからロードされるようになった。これらが初期のオペレーティングシステムのカーネルの元となった。直接実行の手法は今日でも外貨預金 機や組み込みシステムで使われているが、一般に最近のコンピュータではオペレーティングシステムとカーネルが使われている。 UNIX以前の10年間、コンピュータは劇的に能力を向上させ、マシンの未使用時間を使う手法が求められた。この期間の主な開発のひとつがタイムシェアリングシステム (TSS) である。TSSは何人かのユーザーがCPUのタイムスライスをそれぞれ割り当てられる。 タイムシェアリングシステムの開発は多くの問題を発生させた。ひとつの問題は大学のユーザーはCPU時間が欲しいというよりもシステムをハックしたがっているという点である。このためセキュリティやアクセス制御がMulticsプロジェクトの重要な課題となった[10]。もうひとつの問題は計算リソースの正しい扱い方である。ユーザーは計算リソースを使わずに画面を凝視することにほとんどの時間を費やしており、タイムシェアリング方式ではそのようなCPU時間を他のユーザーに与えるべきと考えられた。最終的に、メモリ階層の多層化が進み、リソースの分割が仮想記憶システムの開発へと繋がっていったのである。 UNIXは数十年間のオペレーティングシステム開発の最高点を示している。設計段階では、全ての高レベルのデバイスがファイルとして抽象化されていた。何故ならUNIX設計者は情報処理の目的をデータの変換であると考えていたからである。例えば、プリンタもファイルとして抽象化され、データをそのファイルにコピーすると印字が行われる。他のシステムでは同様の機能を提供するにあたって、デバイスを低レベルに抽象化する傾向があった。デバイスもファイルも何らかの低レベルの概念の実体化である。システムをファイルのレベルで抽象化したことにより、ユーザーは既存のファイル管理機能と概念で全てを扱うことができるようになり、操作が大幅に簡略化された。同じパラダイムを拡張して、UNIXはファイルを複数の小さなプログラムで操作するパイプの概念を可能とした。最終的な結果は同じであっても、このような小さなプログラム群を使うことで柔軟性が劇的に向上しただけでなく、開発も利用も容易になった。 UNIXでは、オペレーティングシステムは2つの部分で構成される。様々な操作を実行するユーティリティプログラム群とカーネルである。プログラミングの観点から見ると両者の違いは小さい。カーネルは特権モードで動作するプログラムであり[2]、プログラムローダーとしての役割とシステムの残りの部分を構成するユーティリティプログラム群を監督する役割を持つ。そして、それらプログラムにロックと入出力サービスを提供する。つまり、カーネルはあらゆる場面に介在しているわけではなかった。 その後、株 モデルが変化し、UNIXの何でもファイルで表す手法が常に適用可能な方法ではなくなってきた。端末はファイルで表せるが（どちらも文字列を読み書きできる）、GUIはそのように扱うことはできない。コンピュータネットワークは別の問題を提起した。ネットワーク経由の通信はファイルアクセスに対応させることができるが、低レベルのパケット指向アーキテクチャはファイルというよりも離散的なデータの塊として扱う必要がある。コンピュータの機能が拡大するにつれ、UNIXのコードは増大していった。初期のカーネルのソースは10万行ほどだったが、Linuxカーネルなどでは450万行にもなっている[11]。 モノリシックカーネルの最大の問題は全体の大きさであった。コードがあまりにも膨大であるため、それを保守したり改造することは困難で時間がかかる作業となったのである。 汎用マイクロカーネルとしてはMachがIPO だが、特定用途向けにもいくつかのマイクロカーネルが開発された。L4はマイクロカーネルの性能が悪くないことを実証するために作られた。ここから派生した新たな実装の Fiasco や Pistachio はLinuxをその上で動作させることができる[12][13]。 QNXはマイクロカーネル設計を採用したリアルタイムオペレーティングシステムであり、1980年代初期に開発され、Machよりも遥かに成功している[14]。ソフトウェアが不正動作することが致命的な状況で使われることが多く、スペースシャトルのロボットアームの制御やガラスを精密に磨く機械の制御で使われている。 ^ a b An overview of Monolithic and Micro Kernels, by K.J. ^ a b 最上位の特権レベルは、スーパーバイザーモード、カーネルモード、CPL0、リング0など様々な呼称がある。 ^ Bona Fide OS Development - Bran's Kernel Development Tutorial, by Brandon Friesen ^ CPU時間は理論上無限だが、メモリ容量とそのアクセス速度は有限であることに注意すべきである。 ^ デバイスドライバをカーネルの一部と見なさない考え方もあるが、例えばリアルタイムクロックなどはカーネル自身が管理する。 ^ 仮想アドレッシングは通常、メモリ管理ユニット (MMU) に内蔵された機能を使用して実現される。 ^ そもそも何故カーネルが大きくなるとまずいのか？ 一般にOSはある程度のハードウェアシリーズで動作するが、その最小メモリサイズは最も安価なハードウェアの最小構成まで考慮する必要があり、そのようなメモリ容量でもある程度の機能が動作しなければならない。このため、少なくとも一般的な構成のカーネルがその最小メモリ容量内に収まって、アプリケーションをそれなりの性能で実行できるだけの空きメモリ容量を確保しなければならないという事情があった。最近ではメモリチップの急速な大容量化によって、このような問題は減りつつある。