カーネル

カーネル︵英: kernel︶は、階層型に設計されたオペレーティングシステム (OS) の中核となる部分で、アプリケーションとハードウェアの架け橋である。具体的には、システムのリソースや、ハードウェアとソフトウェアの連携を管理する^[1]。そのほか、通信制御を行うことが多い。オペレーティングシステムの基本コンポーネントとして、カーネルはメモリ、CPU、入出力を中心としたハードウェアを抽象化し、ハードウェアとソフトウェアがやり取りできるようにする。また、ユーザープログラムのための機能として、プロセスの抽象化、プロセス間通信、システムコールなどを提供する。これらのタスクはカーネルによって方式が異なり、設計や実装も異なる。モノリシックカーネルは全てを一つの仮想アドレス空間に格納されたコードで実行して性能を向上させようとする。マイクロカーネルはサービスの大部分をユーザー空間で実行し、コードの保守性とモジュール性を向上させようとする^[2]^[3]。多くのカーネルはこの二つのカテゴリのいずれか、あるいは中間である。

概要[編集]

全てではないが、多くのオペレーティングシステム (OS) はカーネルを内包する。ハードウェアとソフトウェアの間の通信を管理するソフトウェアとしてのカーネルは、性能、メモリ効率、セキュリティ、プロセッサのアーキテクチャなどが複雑に絡んだ問題への妥協的解答である。多くの場合、ブートローダーがカーネルを特権モードのプロセスとして起動する^[注釈 1]。しかし、初期化が完了すると、カーネルはいわゆるプロセスとしては存在せず、ディスクアクセスなどの高い特権レベルを必要とする処理を必要としたときにユーザプログラムから呼び出される機能の集合体として存在することになる。カーネルの処理の流れはユーザープロセスの処理の流れの延長上にあり、システムコールによってカーネルに処理がわたり、終了するとユーザーに戻っていく。初期化時のコンテキストはそのまま消えるようにする設計もあるが、﹁アイドルプロセス﹂とか﹁collects﹂と呼ばれる、プロセッサが何もすることがないときに実行されるコードに流用される設計とすることもある。省電力のため、プロセッサが﹁休む﹂ような命令を繰り返すようなコードとすることも多い。カーネル開発はプログラミングの中でも複雑で難しいタスクのひとつと考えられる。オペレーティングシステムの中核部であるということは、高い性能を要求される最重要なソフトウェアであり、正しく設計し実装することは難しい。カーネルはユーザプログラムの互換性や移植性を考慮する必要などから、設計が制限されることがあり、そのことがさらに開発を難しくしている。

カーネルの機能[編集]

カーネルの仕事はコンピュータのリソースを管理し、他のプログラムがそれらのリソースを使って動作できるようにすることである^[1]。典型的なリソースとしては以下のものがある。 ●CPU︵プロセッサ︶。コンピュータの中心となる部分で、プログラムの実行を分担する。カーネルは、多数のプログラムの中からプロセッサ︵群︶を割り当てるべきものを選択する。基本的にプロセッサは一度に1つのプロセスしか実行できない︵複数実行できる場合、カーネルは複数のプロセッサとして認識する︶。 ●メモリ。メモリにはプログラムとデータの両方が格納される^[4]^[^注釈 2]。一般にプログラムを実行するには、プログラムとデータの両方がメモリ上になければならない。複数のプログラムがメモリへのアクセスを要求すると、実際に搭載している以上のメモリが必要とされる場合がある。カーネルは各プロセスにメモリを割り当て、全体としてメモリが不足した場合の対処を決定する。 ●コンピュータには何らかの入出力デバイスがある︵キーボード、HDD、USBなど︶。カーネルはアプリケーションから入出力要求を受け付け、適切なデバイス︵あるいはデバイスの一部、たとえばファイルやウィンドウなど︶に対して入出力を実行し、デバイスを使用するための便利な方法を提供する︵一般に、アプリケーションがデバイスの実装の詳細を知らなくてもすむように抽象化する︶^[注釈 3]。リソース管理に必要な重要な観点は、実行領域︵アドレス空間︶の定義とその領域内のリソースへのアクセスを調停する保護機構である^[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カードなどに対応して存在する。一般的なデバイスドライバの抽象化レベルを次に示す。 ●ハードウェア側から見て ●直接インタフェースする。 ●高度なインタフェースを使用する︵ビデオBIOSなど︶。 ●低レベルなデバイスドライバを使用する︵ディスクドライバを使用するファイルシステムドライバなど︶ ●ハードウェアとともにシミュレーションを行う。すなわち、実際には全く異なる何かを行う︵廃れたデバイスの代わりに最新のデバイスを使用するなど︶。 ●ソフトウェア側から見て ●OSがハードウェア資源に直接アクセスできるようにする。 ●ドライバとして基本的な部分だけを実装。 ●ドライバ以外のソフトウェアとのインタフェースを実装︵たとえば、TWAIN︶。 ●何らかの高度な言語を実装︵たとえばPostScript︶。たとえば、ユーザー向けに何かを画面に表示する場合、アプリケーションがカーネルに要求し、その要求がディスプレイドライバに送られ、ディスプレイドライバが実際の文字やピクセルの描画を行う^[7]。カーネルは使用可能なデバイスの一覧を保持しなければならない。この一覧は、事前に知られている場合︵たとえば、組み込みシステムでは利用可能なハードウェアが変われば、カーネルを書き換える︶、ユーザーが設定する場合︵古いPCや個人用に設計されていないシステムなど︶、OSが実行時に検出する場合︵プラグアンドプレイ︶がある。プラグアンドプレイのシステムでは、デバイス管理は最初にさまざまなバス︵PCIやUSB︶上をスキャンして実装されたデバイスを検出し、対応するドライバを探す。デバイス管理は各OS固有の部分であり、カーネルの設計によってドライバの扱い方は異なるが、一般にカーネルはドライバが物理的にデバイスにアクセスするための入出力ポートやメモリ空間を用意する必要がある。デバイスへのアクセスはコンテキストスイッチを引き起こしたり、CPUを浪費したりすることになりやすく、性能オーバヘッドの元となるため、デバイス管理の設計は重要である。

システムコール[編集]

詳細は「システムコール」を参照

意味のある作業を実行するには、ユーザプログラムはカーネルの提供する全サービスにアクセスできなければならない。これはカーネルによって実装が異なるが、多くは標準CライブラリやAPIが提供され、そこから対応するカーネル機能が呼び出される^[9]。カーネル機能を呼び出す方法は主にCPUがどのような機能を提供しているかに依存する。カーネル空間とユーザー空間が分離されている場合、ユーザープロセスが直接カーネルを呼び出すことはできない。たとえば以下のような技法を採用する。 ●例外処理や割り込みを明示的に発生する命令︵トラップ命令、ソフトウェア割り込み︶を使用。多くのハードウェアで実装されている技法である。 ●コールゲートを使用。x86で採用されている。 ●特別なシステムコール命令を使用。最近のx86で実装された。 ●メモリ上のキューを使用。仮想空間の所定の位置にユーザープロセスが要求を投入できるキューを用意し、カーネルがそこから定期的に要求を読み取って実行する。即時性が要求されない場合で、プロセスから複数の要求を行う場合に便利である。

カーネル設計の観点[編集]

保護︵プロテクション︶のサポート[編集]

カーネル設計において重要な観点として、障害︵フォールトトレラント性︶と悪意ある動作︵セキュリティ︶からの保護︵プロテクション︶サポートがある。この2つは通常明確には区別されず、明確に区別しようとするとリングプロテクションでは対応できなくなる^[1]。カーネルが提供する機構または方針は、いくつかの基準で分類できる。 ●静的︵コンパイル時に決定︶か動的︵実行時に決定︶か ●プリエンプティブか事後検出か ●それらが満足する保護原理による分類︵デニング^[10]^[11]︶ ●ハードウェアサポートによる保護か言語サポートによる保護か ●オープンな機構によるものか、方針と密に結合しているかなどである。階層型プロテクションは^[12]、一般に﹁CPUモード﹂でサポートされる。ハードウェアサポートによる単純で効率的な方法は、MMUにメモリアクセスのたびにその妥当性をチェックさせるもので、その機構をケイパビリティベースドアドレッシング︵英語版︶と呼ぶ^[13]。ただし、多くの商用コンピュータアーキテクチャではMMUがケイパビリティをサポートしていない。代替手法は、階層型プロテクションでケイパビリティをシミュレートするものである。この場合、保護されたオブジェクトはアプリケーションがアクセスできないアドレス空間になければならない。カーネルもそのようなメモリ空間のケイパビリティのリストを保持する。ケイパビリティによって保護されたオブジェクトにアプリケーションがアクセスしたい場合、システムコールを行い、カーネルが実際のアクセスを代行する。これにはアドレス空間の切り替えを必要とするため、オブジェクト間で複雑なやりとりが必要なシステムでは性能が低下するが、現代のOSはアクセス頻度が低いオブジェクトや性能を要求されないオブジェクトについてはこの方式を採用している^[14]^[15]。保護機構をより高い階層でシミュレートする方式も可能だが︵たとえば、直接サポートされていないハードウェアについてのページテーブルを操作してケイパビリティをシミュレートするなど︶、性能上の問題がある^[16]。言語ベースの保護を選択するシステムでは、ハードウェアサポートがなくても問題にならない^[17]。カーネル設計における重要な点として、セキュリティの機構と方針を実装する抽象化レベルの選択がある。カーネルのセキュリティ機構は、高度なセキュリティをサポートする上で重要である^[13]^[18]^[1^9]^[20]^[21]。 1つの方式として、ファームウェアとカーネルでフォールトトレラント性をサポートする方式があり、その上に悪意ある動作に対するセキュリティ方針を構築し︵必要に応じて暗号機構を追加する︶、一部の責任をコンパイラに委任する。コンパイラやアプリケーションレベルへのセキュリティ方針の責任委譲の方式を一般に﹁言語ベースのセキュリティ﹂と呼ぶ。現代の主流のOSの多くは重要なセキュリティ機構が欠如しているため、アプリケーションの抽象化レベルでの適切なセキュリティ方針実装ができないことがある^[18]。一般にカーネルサポートがどうであれ、アプリケーションで任意のセキュリティ方針を実装可能だとされているが、間違いである^[18]。

ハードウェアによる保護と言語による保護[編集]

現代の一般的コンピュータは、ハードウェアが強制した規則を使ってプログラムのデータへのアクセスを許可している。プロセッサは動作を監視し、規則に違反したプログラムを停止させる︵たとえば、カーネル空間のメモリを読み書きしようとしたユーザプロセスを停止させるなど︶。ケイパビリティをサポートしていないシステムでは、プロセスは相互に隔離されたアドレス空間で動作する^[22]。ユーザプロセスがカーネルを呼び出すことは、上述したシステムコールの技法を使って統制されている。代替手法として言語ベースの保護︵プロテクション︶がある。言語ベースのプロテクションシステムでは、カーネルは信頼されている言語コンパイラが生成したコードのみ実行を許可する。そしてその言語は、セキュリティに違反するようなコードをプログラマが書けないように設計されている^[17]。この方式には次のような長所がある。 ●アドレス空間を分離する必要がない。アドレス空間の切り替えは低速な操作であり、オーバーヘッドになっているため、現代のOSではその切り替えをなるべく減らすような最適化に多大な労力を費やしている。言語ベースのプロテクションシステムではそのような切り替えが全く不要であり、全コードを同一アドレス空間に置いても安全に運用可能である。 ●柔軟性がある。プログラミング言語でプロテクション機構を表現できるよう設計すれば、この方式ではそれらを実装することが可能である。言語ベースのプロテクションを実現するのにハードウェアを新たに設計する必要はない。一方、次のような短所がある。 ●アプリケーションの起動に時間がかかる。アプリケーションを起動する際に正しいコンパイラで生成されたものか、あるいはソースコードやバイトコードから再コンパイルが必要でないかをチェックする必要がある。 ●型システムが固定される。従来のシステムでは、アプリケーションは型安全でない操作を頻繁に実行する。言語ベースのプロテクションシステムではそのような操作は許されないので、アプリケーションを書き換える必要があり、場合によっては性能が低下することになる。言語ベースのプロテクションを採用したシステムとしては、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であり、実行時にモジュールをロードする機能を備えており、必要に応じて容易に機能を拡張でき、同時にカーネル空間で動作するコード量をなるべく最小に抑えることができる。モノリシックカーネルには次のような長所がある。 ●関係するソフトウェアが少ないので、より高速である。 ●カーネルは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︵のインタフェース︶を使用することができる^[24]。また動的にOSを切り換えたり、複数のOSを同時に使用することもできる^[24]。

モノリシックカーネルとマイクロカーネル[編集]

カーネルが巨大化するにつれて、さまざまな問題が明らかになってきた。最も明らかな問題はカーネルの大きさ︵メモリ使用量︶の増大である。これは仮想記憶をカーネル空間にも適用することである程度まで和らげられるが、全てのコンピュータ・アーキテクチャが仮想記憶をサポートできるわけではない^[注釈 4]。カーネルのサイズを削減するため、不要なコードを削除するなどの改善が必要となるが、これはカーネルの各モジュール間の明らかにされていない依存関係があるために非常に困難である^[注釈 5]。マイクロカーネルと比較したときのモノリシックカーネルのさまざまな欠点から、1990年代の初期までにモノリシックカーネルは時代遅れと考えられるに至った。結果としてLinuxがモノリシックカーネルを採用したことでリーナス・トーバルズとアンドリュー・タネンバウムの間で有名な論争が発生した︵アンドリュー・タネンバウムとリーナス・トーバルズの議論︶^[34]。この議論では、両者の言い分にそれぞれメリットがある。モノリシックカーネルは設計が容易で、マイクロカーネルよりも迅速に成長することが期待できる。しかし、モノリシックカーネル内のバグは一般にシステムクラッシュを引き起こすのに対して、マイクロカーネルでは一部のサーバに問題が限定される。モノリシックカーネルの支持者は、不正なコードがカーネルになければマイクロカーネルの利点はほとんどないと論じる。どちらの側にも成功例がある。マイクロカーネルはロボットや医療用システムで使われており、各コンポーネントが別々の保護されたメモリ空間で動作する。これは最新のモジュールロード方式であってもモノリシックカーネルには不可能であろう。モノリシックカーネルは共有型カーネルメモリを使用するよう最適化されていて、マイクロカーネルのような低速なメッセージわたしとは異なる。

性能[編集]

モノリシックカーネルはコード全体を同じアドレス空間︵カーネル空間︶に置くよう設計されており、一部の開発者はシステム性能向上に必須の特徴だとしている^[35]。一部の開発者はうまく書けばモノリシックカーネルは極めて高効率になるとしている^[35]。 1980年代から1990年代初めにかけてのマイクロカーネルの性能は低かった^[36]^[37]。そういった初期のマイクロカーネルの性能を実測する研究が行われたが、性能が低い原因を深く分析することはなかった^[36]。そういったデータが一人歩きし、カーネルモードとユーザモードの切り替え回数が増え^[36]、プロセス間通信の回数が増え^[36]、コンテキストスイッチの回数が増えたためだ^[36] とみなされた。そして1995年、マイクロカーネルの性能が低い原因として以下のことが推測されている^[36]。 (一)マイクロカーネル﹁方式﹂全体が実際には非効率 (二)マイクロカーネルで実装された﹁コンセプト﹂が非効率 (三)それらコンセプトの特定の﹁実装﹂が非効率この時点でマイクロカーネルを効率化する方法はまだ研究途上であり、正しい技法の構築が求められていた^[36]。一方でモノリシックカーネルの設計の基盤となっている階層型プロテクション^[32] でも、プロテクションの階層間でのやりとりには値︵メッセージ︶のコピーが必要であり、そのやりとりが増えるほど性能が低下することがわかっていた^[38]。近年、L4^[39] やK42︵英語版︶といった新世代のマイクロカーネルが登場し、上述の性能問題をある程度解決している^[要出典]。

ハイブリッドカーネル[編集]

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

Windows NT系などの商用OSでよく見られる。Appleの macOS も、カーネギーメロン大学のMachとFreeBSDのモノリシックカーネルのコードをベースとしたXNUというハイブリッドカーネルを採用している。マイクロカーネルの性能オーバヘッドを削減するため一部のサービス︵通信プロトコルスタックやファイルシステム︶をカーネル空間で動作させるが、一部のカーネルコード︵デバイスドライバなど︶はサーバとしてユーザ空間で実行する。これは、純粋なマイクロカーネルが高性能を提供できると示される以前、妥協的に考案された技法であり、マイクロカーネルにモノリシックカーネルの特性を一部取り入れて拡張したものといえる。ハイブリッドカーネルではカーネルがモジュール化されているが、モジュールの大部分は同じカーネル空間内にロードされる。そのため、バグを含むモジュールをロードするとカーネルの動作が不安定になる可能性がある。マイクロカーネルの場合、カーネルとは全く別の空間でモジュールを動作させることができ、安全に評価することができる。モノリシックカーネルと比較したハイブリッドカーネルの長所を以下に挙げる。 ●モジュールの開発期間が短い。︵カーネルが不安定にならない限り︶評価の際にリブートが不要である。カーネル全体の再コンパイルが不要である。 ●サードパーティーのテクノロジーを素早く統合できる。モジュール群は何らかのモジュールインタフェースを使ってカーネルとやりとりする。そのインタフェースはOS固有ではあるが汎用化されており、常にモジュールとして分離実装できるわけではない。デバイスドライバにはモジュールインタフェース以上の柔軟性が必要なことが多い。基本的にモノリシックカーネルではカーネルとの呼び出しが1回で済むところを、ハイブリッドカーネルでは2回呼び出す必要がある。モジュール化の短所として次の事柄が挙げられる。 ●インタフェースを通る回数が増えるため、バグを作りこむ可能性も増加する︵セキュリティホールも多い可能性がある︶。 ●システム管理者はモジュール群の保守において混乱をきたす可能性がある。

ナノカーネル[編集]

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

エクソカーネル[編集]

エクソカーネル (exokernel) はまだ実験段階のOS設計技法である。他のカーネルとの違いは、物理ハードウェアのプロテクションと多重化に機能を限定している点で、アプリケーションに対して全くハードウェアの抽象化を提供しない。このようにハードウェアのプロテクションをハードウェア管理から分離することで、利用可能なハードウェアを最大限に生かすように個々のプログラムを開発できるという利点が生じる。エクソカーネル自体は非常に小さい。しかし、通常のOSの持つ機能をアプリケーション開発者に提供するためのライブラリ型OSを伴う。エクソカーネル型システムの最大の利点は、このライブラリ型OS機能を複数用意できるという点で、それぞれが異なるAPIを提供できる。たとえば同じシステム上で、高度なUIを持つアプリケーションを開発し、同時にリアルタイムシステム制御を行うアプリケーションも開発できる。

カーネル開発史[編集]

初期のOSカーネル[編集]

詳細は「オペレーティングシステムの歴史」を参照

厳密にいえば、オペレーティングシステム︵とカーネル︶はコンピュータを動作させるのに必須ではない。プログラムはマシン上に直接ロードされ実行されることも可能であり、そのようなプログラムはOSのサービスや抽象化なしで記述しなければならない。多くの初期のコンピュータではそのような手法が一般的であり、プログラムを入れ替えるときにリセットとリロードが必要だった。その後、プログラムローダーやデバッガといった補助的な小さなプログラムがメモリに常駐したり、ROMからロードされるようになった。これらが初期のオペレーティングシステムのカーネルの元となった。直接実行の手法は今日でもゲーム機や組み込みシステムで使われているが^[41]、一般に最近のコンピュータではオペレーティングシステムとカーネルが使われている。 1969年の RC 4000 Multiprogramming System では、小さな中核部の上で異なる目的のOS群を整然とした方法で構築するというシステム設計哲学を導入しており^[42]、マイクロカーネル方式のさきがけとなっている。

タイムシェアリングOS[編集]

詳細は「タイムシェアリングシステム」を参照

UNIX以前の10年間、コンピュータは劇的に能力を向上させ、マシンの未使用時間を使う手法が求められた。この期間の主な開発のひとつがタイムシェアリングシステム (TSS) である。TSSは何人かのユーザーがCPUのタイムスライスをそれぞれ割り当てられる^[43]。タイムシェアリングシステムの開発は多くの問題を発生させた。ひとつの問題は大学のユーザーはCPU時間が欲しいというよりもシステムをハックしたがっているという点である。このためセキュリティやアクセス制御が1965年のMulticsプロジェクトの重要な課題となった^[44]。もうひとつの問題は計算リソースの正しい扱い方である。ユーザーは計算リソースを使わずに画面を凝視することにほとんどの時間を費やしており、タイムシェアリング方式ではそのようなCPU時間を他のユーザーに与えるべきと考えられた。最終的に、メモリ階層の多層化が進み、リソースの分割が仮想記憶システムの開発へと繋がっていったのである。

UNIX[編集]

詳細は「UNIX」を参照

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 などがある。

Mac OS[編集]

Appleは1984年、最初のMac OSを同社のパーソナルコンピュータ Macintoshに同梱して発売した。後継のmacOSはDarwinをベースとしており、4.4BSDユーザーランドとMachカーネルを統合したXNUと呼ばれるハイブリッドカーネルを採用している^[48]。

Microsoft Windows[編集]

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]。ソフトウェアが不正作動することが致命的な状況で使われることが多く、スペースシャトルのロボットアームの制御やガラスを精密に磨く機械の制御で使われている。

脚注[編集]

[脚注の使い方]

注釈[編集]

(一)^ ^a ^b最上位の特権レベルは、スーパーバイザーモード、カーネルモード、CPL0、リング0など様々な呼称がある。 (二)^ CPU時間は理論上無限だが、メモリ容量とそのアクセス速度は有限であることに注意すべきである。 (三)^ デバイスドライバをカーネルの一部とみなさない考え方もあるが、たとえばリアルタイムクロックなどはカーネル自身が管理する。 (四)^ 仮想アドレッシングは通常、メモリ管理ユニット (MMU) に内蔵された機能を使用して実現される。 (五)^ そもそも何故カーネルが大きくなるとまずいのか？一般にOSはある程度のハードウェアシリーズで動作するが、その最小メモリサイズは最も安価なハードウェアの最小構成まで考慮する必要があり、そのようなメモリ容量でもある程度の機能が動作しなければならない。このため、少なくとも一般的な構成のカーネルがその最小メモリ容量内に収まって、アプリケーションをそれなりの性能で実行できるだけの空きメモリ容量を確保しなければならないという事情があった。最近ではメモリチップの急速な大容量化によって、このような問題は減りつつある。

出典[編集]

(一)^ ^a ^b ^c ^d ^e ^f ^g ^h ⁱWulf 1974, pp. 337–345 (二)^ ^a ^bAn overview of Monolithic and Micro Kernels, by K.J. (三)^ Roch 2004 (四)^ Bona Fide OS Development - Bran's Kernel Development Tutorial, by Brandon Friesen (五)^ Levy 1984, p. 5 (六)^ Needham, R.M., Wilkes, M. V. Domains of protection and the management of processes, Computer Journal, vol. 17, no. 2, May 1974, pp 117–120. (七)^ ^a ^b ^cSilberschatz 1991 (八)^ http://www.answers.com/topic/operating-system (九)^ Tanenbaum, Andrew S. (2008). Modern Operating Systems (3rd ed.). Prentice Hall. pp. 50–51. ISBN 0-13-600663-9. ". . . nearly all system calls [are] invoked from C programs by calling a library procedure . . . The library procedure . . . executes a TRAP instruction to switch from user mode to kernel mode and start execution . . ." (十)^ Denning 1976 (11)^ Swift 2005, p. 29 quote: "isolation, resource control, decision verification (checking), and error recovery." (12)^ Schroeder 1972 (13)^ ^a ^bLinden 1976 (14)^ Stephane Eranian and David Mosberger, Virtual Memory in the IA-64 Linux Kernel, Prentice Hall PTR, 2002 (15)^ Silberschatz 1993, pp. 445, 446 (16)^ Hoch, Charles; J. C. Browne (University of Texas, Austin) (July 1980). “An implementation of capabilities on the PDP-11/45” (PDF). ACM SIGOPS Operating Systems Review 14 (3): 22–32. doi:10.1145/850697.850701 2007年1月7日閲覧。. (17)^ ^a ^bA Language-Based Approach to Security, Schneider F., Morrissett G. (Cornell University) and Harper R. (Carnegie Mellon University) (18)^ ^a ^b ^cP. A. Loscocco, S. D. Smalley, P. A. Muckelbauer, R. C. Taylor, S. J. Turner, and J. F. Farrell. The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments. In Proceedings of the 21st National Information Systems Security Conference, pages 303–314, Oct. 1998. (19)^ J. Lepreau et al. The Persistent Relevance of the Local Operating System to Global Applications. Proceedings of the 7th ACM SIGOPS European workshop, 1996. (20)^ J. Anderson, Computer Security Technology Planning Study, Air Force Elect. Systems Div., ESD-TR-73-51, October 1972. (21)^ Jerry H. Saltzer, Mike D. Schroeder (September 1975). “The protection of information in computer systems”. Proceedings of the IEEE 63 (9): 1278–1308. doi:10.1109/PROC.1975.9939. (22)^ Jonathan S. Shapiro; Jonathan M. Smith; David J. Farber (1999). “EROS: a fast capability system”. Proceedings of the seventeenth ACM symposium on Operating systems principles 33 (5): 170–185. doi:10.1145/319344.319163. (23)^ Dijkstra, E. W. Cooperating Sequential Processes. Math. Dep., Technological U., Eindhoven, Sept. 1965. (24)^ ^a ^b ^c ^d ^e ^fHansen 1970, pp. 238–241 (25)^ “SHARER, a time sharing system for the CDC 6600”. 2007年1月7日閲覧。 (26)^ “Dynamic Supervisors – their design and construction”. 2007年1月7日閲覧。 (27)^ Baiardi 1988 (28)^ ^a ^bLevin 1975 (29)^ Denning 1980 (30)^ Jürgen Nehmer The Immortality of Operating Systems, or: Is Research in Operating Systems still Justified? Lecture Notes In Computer Science; Vol. 563. Proceedings of the International Workshop on Operating Systems of the 90s and Beyond. pp. 77–83 (1991) ISBN 3-540-54987-0 [1] quote: "The past 25 years have shown that research on operating system architecture had a minor effect on existing main stream systems." [2] (31)^ Levy 1984, p. 1 quote: "Although the complexity of computer applications increases yearly, the underlying hardware architecture for applications has remained unchanged for decades." (32)^ ^a ^b ^cLevy 1984, p. 1 quote: "Conventional architectures support a single privileged mode of operation. This structure leads to monolithic design; any module needing protection must be part of the single operating system kernel. If, instead, any module could execute within a protected domain, systems could be built as a collection of independent modules extensible by any user." (33)^ Open Sources: Voices from the Open Source Revolution (34)^ Linus vs. Tanenbaum や LINUX is obsolete - comp.os.minix や Appendix A The Tanenbaum-Torvalds Debate に議論の記録がある (35)^ ^a ^bMatthew Russell. “What Is Darwin (and How It Powers Mac OS X)”. O'Reilly Media. 2012年9月30日閲覧。 quote: "The tightly coupled nature of a monolithic kernel allows it to make very efficient use of the underlying hardware [...] Microkernels, on the other hand, run a lot more of the core processes in userland. [...] Unfortunately, these benefits come at the cost of the microkernel having to pass a lot of information in and out of the kernel space through a process known as a context switch. Context switches introduce considerable overhead and therefore result in a performance penalty." (36)^ ^a ^b ^c ^d ^e ^f ^gLiedtke 1995 (37)^ Härtig 1997 (38)^ Hansen 1973, section 7.3 p.233 "interactions between different levels of protection require transmission of messages by value" (39)^ ^a ^bThe L4 microkernel family – Overview (40)^ KeyKOS Nanokernel Architecture (41)^ Ball 2002, p. 129 (42)^ Hansen 2001, pp. 17–18 (43)^ BSTJ version of C.ACM Unix paper (44)^ Introduction and Overview of the Multics System, by F. J. Corbató and V. A. Vissotsky. (45)^ ^a ^bThe UNIX System — The Single Unix Specification (46)^ Unix’s Revenge by Horace Dediu (47)^ Linux Kernel 2.6: It's Worth More!, by David A. Wheeler, 2004年10月12日。 (48)^ XNU: The Kernel (49)^ Windows History: Windows Desktop Products History (50)^ The Fiasco microkernel - Overview (51)^ L4Ka - The L4 microkernel family and friends (52)^ QNX Realtime Operating System Overview

参考文献[編集]

●Roch, Benjamin (2004年). “Monolithic kernel vs. Microkernel” (PDF). 2006年10月12日閲覧。 ●Silberschatz, Abraham; James L. Peterson, Peter B. Galvin (1991). Operating system concepts (3rd ed.). Boston, Massachusetts: Addison-Wesley. p. 696. ISBN 0-201-51379-X ●Silberschatz, Abraham; Peter B. Galvin (1993). Operating system concepts (4th ed.). Boston, Massachusetts: Addison-Wesley. ISBN 0-201-50480-4 ●Ball, Stuart R. (2002). Embedded Microprocessor Systems: Real World Designs (first ed.). Elsevier Science. ISBN 0-7506-7534-9 ●Denning, Peter J. (December 1976). “Fault tolerant operating systems”. ACM Computing Surveys 8 (4): 359–389. doi:10.1145/356678.356680. ISSN 0360-0300. ●Denning, Peter J. (April 1980). “Why not innovations in computer architecture?”. ACM SIGARCH Computer Architecture News 8 (2): 4–7. doi:10.1145/859504.859506. ISSN 0163-5964. ●Hansen, Per Brinch (April 1970). “The nucleus of a Multiprogramming System”. Communications of the ACM 13 (4): 238–241. doi:10.1145/362258.362278. ISSN 0001-0782. ●Hansen, Per Brinch (1973). Operating System Principles. Englewood Cliffs: Prentice Hall. p. 496. ISBN 0-13-637843-9 ●Hansen, Per Brinch (2001) (PDF). The evolution of operating systems 2006年10月24日閲覧。. included in book: Per Brinch Hansen, ed (2001). “1”. Classic operating systems: from batch processing to distributed systems. New York,: Springer-Verlag. pp. 1–36. ISBN 0-387-95113-X ●Härtig, Hermann; Michael Hohmuth, Jochen Liedtke, Sebastian Schönberg, Jean Wolter (1997). “The performance of μ-kernel-based systems”. ACM SIGOPS Operating Systems Review 31 (5): 66-77 2010年6月19日閲覧。. ●Levin, R.; E. Cohen, W. Corwin, F. Pollack,William Wulf (1975). “Policy/mechanism separation in Hydra”. ACM Symposium on Operating Systems Principles / Proceedings of the fifth ACM symposium on Operating systems principles 9 (5): 132–140. doi:10.1145/1067629.806531. ●Levy, Henry M. (1984). Capability-based computer systems. Maynard, Mass: Digital Press. ISBN 0-932376-22-3 ●Liedtke, Jochen (1995-12). “On µ-Kernel Construction”. Proc. 15th ACM Symposium on Operating System Principles (SOSP). ●Linden, Theodore A. (December 1976). “Operating System Structures to Support Security and Reliable Software”. ACM Computing Surveys 8 (4): 409–445. doi:10.1145/356678.356682. ISSN 0360-0300., “Operating System Structures to Support Security and Reliable Software” (PDF). 2010年6月19日閲覧。 ●Schroeder, Michael D.; Jerome H. Saltzer (March 1972). “A hardware architecture for implementing protection rings”. Communications of the ACM 15 (3): 157–170. doi:10.1145/361268.361275. ISSN 0001-0782. ●Wulf, W.; E. Cohen, W. Corwin, A. Jones, R. Levin, C. Pierson, F. Pollack (June 1974). “HYDRA: the kernel of a multiprocessor operating system”. Communications of the ACM 17 (6): 337–345. doi:10.1145/355616.364017. ISSN 0001-0782. ●Baiardi, F.; A. Tomasi, M. Vanneschi (1988) (Italian). Architettura dei Sistemi di Elaborazione, volume 1. Franco Angeli. ISBN 88-204-2746-X ●Swift, Michael M.; Brian N. Bershad, Henry M. Levy (February 2005). “Improving the reliability of commodity operating systems”. ACM Transactions on Computer Systems 23 (1): 77-110. doi:10.1002/spe.4380201404.

外部リンク[編集]

Detailed comparison between most popular operating system kernels

[1]

[2]

[3]

[注釈 1]

[4]

[

[注釈 3]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[1

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30

[31]

[32]

[

[注釈 4]

[注釈 5]

[34]

[35]

[36]

[37]

[38]

[39]

[40]

[41]

[42]

[43]

[44]

[45]

[46]

[47]

[48]

[49]

[50]

[51]

[52]