カーネル カーネル全体の設計方針

ウィキペディア

カーネル

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2023/09/23 03:13 UTC 版)

カーネル全体の設計方針

もちろん、上述したタスク群や機能群の提供方法は設計や実装の面でさまざまである。

「機構と方針の分離」の原則は、マイクロカーネルとモノリシックカーネルの哲学の間でかなり大きな相違がある。ここで、「機構」はさまざまな「方針」の実装を可能とするものであり、「方針」は特定の「操作のモード」である。たとえば「機構」面では、ユーザーがログインしようとしたとき認証サーバを呼び出してアクセスを認めるべきか否かを決定するということが考えられる。一方「方針」面では、認証サーバがパスワードを要求し、データベース内の暗号化されたパスワードと照合するかもしれない。機構が汎用的であれば、機構と方針が同一モジュールに統合されている場合よりも方針の変更（たとえば、パスワードの代わりにセキュリティトークンを使うなど）がより容易になる。

最小のマイクロカーネルでは非常に基本的な方針のみが含まれ、その機構はカーネル上で動作させるもの（OSの残りの部分やアプリケーション群）自身がどのような方針（メモリ管理、高度なプロセススケジューリング、ファイルシステム管理など）を採用するか決定することを可能にする。一方モノリシックカーネルは方針の大部分をカーネル内に含む傾向があり、結果としてその上の部分の自由度は制限される。

Per Brinch Hansen は機構と方針の分離のための主張を展開した。すなわち、この分離が不適切であることが既存のOSで本質的技術革新が見られないことの主要因だとし、コンピュータアーキテクチャにおける共通課題だとした。モノリシック設計は、従来の商用システムで一般的な保護技法である「カーネルモード」と「ユーザーモード」に分離するアーキテクチャ（いわゆるリングプロテクション）から生まれた。そのアーキテクチャでは、保護（プロテクション）を必要とするモジュールを可能な限りカーネルに含めようとする。このようなモノリシック設計と特権モードの関係が機構と方針の分離における重要な問題として再注目されている。実際「特権モード」のアーキテクチャ技法は保護機構とセキュリティ方針を融合させる傾向があるが、これとは大きく異なるアーキテクチャ技法であるケイパビリティベースドアドレッシングではその2つを明確に区別し、自然にマイクロカーネル設計が可能となる。

モノリシックカーネルはカーネルの全コードを同じアドレス空間（カーネル空間）で実行するが、マイクロカーネルでは多くのサービスをユーザー空間で実行しようとし、コードベースの保守性とモジュール性を向上させようとしている。多くのカーネルは明確にどちらかに分類できるわけではなく、その中間の実装ともいうべきハイブリッドカーネルになっている。さらに特殊な設計としてナノカーネルやエクソカーネルが研究されているが、広く使われるまでには至っていない。エクソカーネルの例としてXenハイパーバイザがある。

モノリシックカーネル

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

モノリシックカーネルでは、全OSサービスはひとつのカーネル空間内に存在し、カーネルスレッド上で実行される。この手法は強力なハードウェアアクセスを提供する。UNIXの開発者ケン・トンプソンは、モノリシックカーネルの方がマイクロカーネルより実装が容易だとしている。主な欠点はシステム構成要素間の依存関係の複雑さである。たとえば、デバイスドライバにバグがあっただけでシステム全体がクラッシュするし、大きなカーネルは保守が非常に困難である。

Unix系OSが伝統的に採用してきたモノリシックカーネルは、OS中核機能とデバイスドライバを全て含んでいた。デバイスドライバ、スケジューラ、メモリ管理、ファイルシステム、ネットワークのプロトコルスタックなど、多くのプログラムが必要とするがライブラリとしてユーザー空間で実行することができない機能は、全てカーネル空間に置かれた。それら全サービスへのアクセスを可能にするため、数多くのシステムコールがアプリケーションに対して提供されている。

必要とされないサブシステムを伴って最初からロードされるモノリシックカーネルは、より汎用的な意味ではあるが、特定ハードウェア向けに設計されたものよりもチューニングが可能である。LinuxやFreeBSDなどの現代のモノリシックカーネルはUnix系OSであり、実行時にモジュールをロードする機能を備えており、必要に応じて容易に機能を拡張でき、同時にカーネル空間で動作するコード量をなるべく最小に抑えることができる。モノリシックカーネルには次のような長所がある。

• 関係するソフトウェアが少ないので、より高速である。
• カーネルは1つのソフトウェアであるため、ソースコード量もコンパイル後の実行ファイルの大きさも小さくなる。
• コードが少ないのでバグも少なく、結果としてセキュリティ問題も比較的少ない。

モノリシックカーネルはシステムコールの延長で動作する部分がほとんどである。システムコールは一般にテーブル構造で保持されるインタフェースであり、ディスク操作などのカーネル内サブシステムへのアクセスを行う。プログラム内でライブラリルーチンを呼び出すと、その中で要求をチェックしてコピーし、システムコールにわたす。したがって、それほど重い呼び出しではない。Linuxカーネルはモノリシックだがかなり小さくできる。これは、ローダブル・カーネル・モジュール機能と、カスタマイズが容易なためである。実際、フロッピーディスク1枚にカーネルだけでなく多数のユーティリティを搭載し、それだけで完動するOSとすることもできる（最も有名な例として muLinux がある）。このカーネルを小型化できる能力があるため、Linuxは組み込みシステムで急速に採用が増えている（組み込みLinux）。

このようなカーネルはOSの中核機能とデバイスドライバからなり、実行時にモジュールをロードする機能を備えている。それらによって、下層のハードウェアについての豊富で強力な抽象化を提供する。それらは単純なハードウェア抽象化の小さなセットを提供し、サーバと呼ばれるアプリケーションを使ってさらなる機能を提供する。この特定の手法でハードウェア上の高度な仮想インタフェースを定義し、プロセス管理、並行性管理、メモリ管理といったスーパーバイザモードで動作するいくつかのモジュールでOSサービスを実装し、システムコールでそれらを呼び出せるようにしている。しかし、このような設計には以下のような短所や制約がある。

• カーネル内のコーディングは難しい。標準Cライブラリが使えず、デバッグにはGNUデバッガなどのソースレベルのデバッガを必要とするためである。そのため、開発中はコンピュータを頻繁にリブートする必要がある。これは単に開発者だけの問題ではない。デバッグが難しいということはバグをつぶすのが難しいということであり、カーネル内にバグが残存しやすいということでもある。
• カーネル内のバグは重大な副作用を引き起こす。カーネル内の関数はどれも特権状態で動作するので、全く無関係なデータ構造を（カーネル空間内でもユーザー空間内でも）容易に壊すことができる。モジュール群は同一アドレス空間で動作するので、バグによってシステム全体をダウンさせることがある。
• カーネルは肥大化しやすく、肥大化すると保守が困難になる。
• コードの結合度が強く、モジュール化して分離したとしても、その分離を正しく行うのは困難である。
• 移植性が低い。動作させるアーキテクチャごとに書き直しが必須となる。

マイクロカーネル

マイクロカーネル方式では、カーネルはサーバの実行に必要な最小限の機能をカーネルに持たせ、それ以外のカーネル機能（デバイスドライバ、GUIなど）はサーバという別個のプログラムで実装する。

マイクロカーネルとは、伝統的な「カーネル」から「サーバ」群に機能を移転するOS設計方針を意味し、最小化したカーネルだけをカーネル空間に残し、サーバ群を可能なかぎりユーザ空間で動作させる。マイクロカーネルでは、ハードウェアの単純な抽象化と最小のプリミティブ（システムコール）で最小のOSサービスを実装する（メモリ管理、マルチタスク、プロセス間通信など）。他の全てのサービス（ネットワークなど）は「サーバ」としてユーザ空間に実装される。マイクロカーネルはモノリシックカーネルよりも保守が容易だが、システムコール回数やコンテキストスイッチ回数が増大するために性能が低下する傾向がある。

どうしても特権モードでなければならない部分だけがカーネル空間に置かれる。それは、IPC（プロセス間通信）、基本スケジューラ（スケジューリング・プリミティブ）、基本メモリハンドラ、基本I/Oプリミティブなどである。スケジューラ本体やメモリ管理、ファイルシステム、ネットワークスタックといった大部分はユーザ空間で動作する。マイクロカーネルは、システム機能全体がプロセッサのシステムモードで動作する1つのプログラムになっているモノリシックカーネルの設計方針への反発から生まれた。マイクロカーネルを採用したOSとしては、QNXや GNU Hurd がある。マイクロカーネルは基本的に次のような長所を持つ。

• 保守は相対的に容易である。
• パッチの評価が容易である。
• すばやく開発でき、多くの場合カーネルを再起動しなくとも評価可能。
• サーバで障害が発生しても、運用上のミラーで代行可能なことが多く、バグへの耐性が高い。

多くのマイクロカーネルは、何らかのメッセージパッシングシステムを採用しており、サーバからサーバへの要求の転送を行う。一般にマイクロカーネルがそのためのポートを用意している。たとえばメモリ追加要求を送ると、マイクロカーネルのあるポートが開き、そこを通して要求が転送される。マイクロカーネルにメッセージが受信されると、その後はシステムコールのように処理される。これによってシステムアーキテクチャのモジュール性が高まり、システムがより整理され、デバッグや動的変更が容易になり、ユーザーのニーズに従ったカスタマイズが可能となる。AIX、BeOS、Hurd、macOS、MINIX、QNX といったOSは多かれ少なかれマイクロカーネルの設計方針を取り入れている。マイクロカーネル自体は非常に小さいが、システム機能全体を構成するコードを全て集めると、モノリシックカーネルよりも大きいことが多い。モノリシックカーネル支持派はまた、マイクロカーネル方式の2層構造によりOSの大部分がハードウェアと直接相互作用できなくなるため、決して小さくないコストが上乗せされ、システムの効率を低下させると主張している。マイクロカーネルは通常、アドレス空間定義部、プロセス間通信 (IPC)、プロセス管理といった最小限のサービスだけを提供する。ハードウェア処理といった他の機能はマイクロカーネルで直接扱うことはない。マイクロカーネル支持派は、モノリシックカーネルでのエラー（バグ）がシステム全体のクラッシュを引き起こすという欠点を指摘する。しかしマイクロカーネルでは、サーバがクラッシュしてもそのサービスを再起動することでシステム全体のクラッシュを防ぐ可能性がある。しかし、現にLinuxなどのモノリシックカーネルは年単位で安定動作している実績があり、このようなマイクロカーネルの利点がどれほど重要かは疑わしい。

ネットワーキングなどのカーネルサービスは「サーバ」と呼ばれるユーザ空間のプログラムとして実装される。サーバを停止・再起動するだけでOSを更新可能である。たとえばネットワークをサポートしていないマシンで、ネットワークサーバは起動する必要がない。サーバ群やカーネルの間でデータをやり取りする作業があるため、モノリシックカーネルにはないオーバヘッドが生じ、効率が低下する。

マイクロカーネルの短所はたとえば次のようなものがある。

• 全体としてメモリをより多く使用する。
• インタフェースを持つソフトウェアの数が多く、性能低下の可能性がある。
• サーバ群とカーネル間のメッセージングにバグがあると、検出が困難である。
• プロセス管理は一般に非常に複雑になりうる。
• 使用状況によってはマイクロカーネルは不利になる。単一用途のシステムでは動作するプロセス数が小さいため、マイクロカーネルがよく機能し、プロセス管理の複雑さもあまり問題にならない。

マイクロカーネル方式では、OSの他の部分を通常のアプリケーションのように高水準言語で書くことができ、同一のカーネル上で異なるOS（のインタフェース）を使用することができる。また動的にOSを切り換えたり、複数のOSを同時に使用することもできる。

モノリシックカーネルとマイクロカーネル

カーネルが巨大化するにつれて、さまざまな問題が明らかになってきた。最も明らかな問題はカーネルの大きさ（メモリ使用量）の増大である。これは仮想記憶をカーネル空間にも適用することである程度まで和らげられるが、全てのコンピュータ・アーキテクチャが仮想記憶をサポートできるわけではない。カーネルのサイズを削減するため、不要なコードを削除するなどの改善が必要となるが、これはカーネルの各モジュール間の明らかにされていない依存関係があるために非常に困難である。

マイクロカーネルと比較したときのモノリシックカーネルのさまざまな欠点から、1990年代の初期までにモノリシックカーネルは時代遅れと考えられるに至った。結果としてLinuxがモノリシックカーネルを採用したことでリーナス・トーバルズとアンドリュー・タネンバウムの間で有名な論争が発生した（アンドリュー・タネンバウムとリーナス・トーバルズの議論）。この議論では、両者の言い分にそれぞれメリットがある。

モノリシックカーネルは設計が容易で、マイクロカーネルよりも迅速に成長することが期待できる。しかし、モノリシックカーネル内のバグは一般にシステムクラッシュを引き起こすのに対して、マイクロカーネルでは一部のサーバに問題が限定される。モノリシックカーネルの支持者は、不正なコードがカーネルになければマイクロカーネルの利点はほとんどないと論じる。どちらの側にも成功例がある。マイクロカーネルはロボットや医療用システムで使われており、各コンポーネントが別々の保護されたメモリ空間で動作する。これは最新のモジュールロード方式であってもモノリシックカーネルには不可能であろう。モノリシックカーネルは共有型カーネルメモリを使用するよう最適化されていて、マイクロカーネルのような低速なメッセージわたしとは異なる。

性能

モノリシックカーネルはコード全体を同じアドレス空間（カーネル空間）に置くよう設計されており、一部の開発者はシステム性能向上に必須の特徴だとしている。一部の開発者はうまく書けばモノリシックカーネルは極めて高効率になるとしている。

1980年代から1990年代初めにかけてのマイクロカーネルの性能は低かった。そういった初期のマイクロカーネルの性能を実測する研究が行われたが、性能が低い原因を深く分析することはなかった。そういったデータが一人歩きし、カーネルモードとユーザモードの切り替え回数が増え、プロセス間通信の回数が増え、コンテキストスイッチの回数が増えたためだ とみなされた。

そして1995年、マイクロカーネルの性能が低い原因として以下のことが推測されている。

1. マイクロカーネル「方式」全体が実際には非効率
2. マイクロカーネルで実装された「コンセプト」が非効率
3. それらコンセプトの特定の「実装」が非効率

この時点でマイクロカーネルを効率化する方法はまだ研究途上であり、正しい技法の構築が求められていた。

一方でモノリシックカーネルの設計の基盤となっている階層型プロテクション でも、プロテクションの階層間でのやりとりには値（メッセージ）のコピーが必要であり、そのやりとりが増えるほど性能が低下することがわかっていた。

近年、L4 やK42といった新世代のマイクロカーネルが登場し、上述の性能問題をある程度解決している。

ハイブリッドカーネル

モノリシックカーネルの高速性・単純性とマイクロカーネルのモジュール性・拡張性を組み合わせたのがハイブリッドカーネルである。

Windows NT系などの商用OSでよく見られる。Appleの macOS も、カーネギーメロン大学のMachとFreeBSDのモノリシックカーネルのコードをベースとしたXNUというハイブリッドカーネルを採用している。マイクロカーネルの性能オーバヘッドを削減するため一部のサービス（通信プロトコルスタックやファイルシステム）をカーネル空間で動作させるが、一部のカーネルコード（デバイスドライバなど）はサーバとしてユーザ空間で実行する。これは、純粋なマイクロカーネルが高性能を提供できると示される以前、妥協的に考案された技法であり、マイクロカーネルにモノリシックカーネルの特性を一部取り入れて拡張したものといえる。

ハイブリッドカーネルではカーネルがモジュール化されているが、モジュールの大部分は同じカーネル空間内にロードされる。そのため、バグを含むモジュールをロードするとカーネルの動作が不安定になる可能性がある。マイクロカーネルの場合、カーネルとは全く別の空間でモジュールを動作させることができ、安全に評価することができる。モノリシックカーネルと比較したハイブリッドカーネルの長所を以下に挙げる。

• モジュールの開発期間が短い。（カーネルが不安定にならない限り）評価の際にリブートが不要である。カーネル全体の再コンパイルが不要である。
• サードパーティーのテクノロジーを素早く統合できる。

モジュール群は何らかのモジュールインタフェースを使ってカーネルとやりとりする。そのインタフェースはOS固有ではあるが汎用化されており、常にモジュールとして分離実装できるわけではない。デバイスドライバにはモジュールインタフェース以上の柔軟性が必要なことが多い。基本的にモノリシックカーネルではカーネルとの呼び出しが1回で済むところを、ハイブリッドカーネルでは2回呼び出す必要がある。モジュール化の短所として次の事柄が挙げられる。

• インタフェースを通る回数が増えるため、バグを作りこむ可能性も増加する（セキュリティホールも多い可能性がある）。
• システム管理者はモジュール群の保守において混乱をきたす可能性がある。

ナノカーネル

ナノカーネルは全てのサービスをデバイスドライバとして分離する。これにはたとえば最も基本的な割り込みコントローラやタイマーの制御も含まれる。これによりカーネルメモリはマイクロカーネルよりもさらに小さくなる。

エクソカーネル

エクソカーネル (exokernel) はまだ実験段階のOS設計技法である。他のカーネルとの違いは、物理ハードウェアのプロテクションと多重化に機能を限定している点で、アプリケーションに対して全くハードウェアの抽象化を提供しない。このようにハードウェアのプロテクションをハードウェア管理から分離することで、利用可能なハードウェアを最大限に生かすように個々のプログラムを開発できるという利点が生じる。

エクソカーネル自体は非常に小さい。しかし、通常のOSの持つ機能をアプリケーション開発者に提供するためのライブラリ型OSを伴う。エクソカーネル型システムの最大の利点は、このライブラリ型OS機能を複数用意できるという点で、それぞれが異なるAPIを提供できる。たとえば同じシステム上で、高度なUIを持つアプリケーションを開発し、同時にリアルタイムシステム制御を行うアプリケーションも開発できる。