カーネル
出典: フリー百科事典『ウィキペディア（Wikipedia）』
カーネル（英：Kernel）とは、階層型に設計されたオペレーティングシステムの中核となる部分である。システムのリソースを管理し、ハードウェアとソフトウェアコンポーネントのやりとりを管理する。
オペレーティングシステムの基本コンポーネントとして、カーネルはメモリ、CPU、入出力を中心としたハードウェアを抽象化し、ハードウェアとソフトウェアがやり取りできるようにする。また、ユーザープログラムのための機能として、プロセスの抽象化、プロセス間通信、システムコールなどを提供する。
これらのタスクはカーネルによって方式が異なり、設計も実装も異なる。モノリシックカーネルは全てを一つの仮想アドレス空間に格納されたコードで実行して性能を向上させようとする。マイクロカーネルはサービスの大部分をユーザ空間で実行し、コードの保守性とモジュール性を向上させようとする[1]。多くのカーネルはこの二つのカテゴリのいずれか（あるいは中間）である。
目次 |
[編集] 概要
全てではないが、多くのオペレーティングシステムはカーネルを内包する。ハードウェア/ソフトウェア間の通信を管理するソフトウェアとしてのカーネルは、性能、メモリ効率、セキュリティ、プロセッサのアーキテクチャなどが複雑に絡んだ問題への妥協的解答である。
多くの場合、ブートローダーがカーネルを特権モードのプロセスとして起動する[2]。しかし、初期化が完了すると、カーネルはいわゆるプロセスとしては存在せず、ディスクアクセスなどの高い特権レベルを必要とする処理を必要としたときにユーザプログラムから呼び出される機能の集合体として存在することになる。カーネルの処理の流れはユーザープロセスの処理の流れの延長上にあり、システムコールによってカーネルに処理が渡り、終了するとユーザーに戻っていく。初期化時のカーネルの処理の流れは「アイドルプロセス」とか「collects」と呼ばれ、プロセッサが何もしていないときに実行される。
カーネル開発はプログラミングの中でも最も複雑で難しいタスクのひとつと考えられる。オペレーティングシステムの中核部であるということは、高い性能を要求される最重要なソフトウェアであり、正しく設計し実装することは難しい。カーネルはユーザプログラムの互換性や移植性を考慮する必要などから、設計が制限されることもあり、そのことがさらに開発を難しくしている。
[編集] カーネルの機能
カーネルの仕事はコンピュータのリソースを管理し、他のプログラムがそれらのリソースを使って動作できるようにすることである。コンピュータの最も基本となる部品はCPUまたはマイクロプロセッサであり、それらが実際に様々なプログラムをカーネルの管理下で実行する。他の重要なリソースはコンピュータのメモリであり、実行すべきプログラムがそこにロードされ、プログラムが使用するデータも格納される[3][4]。さらにデバイスへのアクセスを可能とするため、カーネルはマザーボードの入出力も管理しなければならない[5]。最終的にカーネルはそれらのサービスにユーザープログラムがアクセスする手段を提供しなければならない。
[編集] プロセス管理
- 詳細はプロセス管理を参照
OSカーネルの主な仕事はアプリケーションの実行を許可し、ハードウェア抽象化などの機能によってそれをサポートすることである。アプリケーションを実行するため、カーネルはアプリケーションのコードを含むファイルをメモリにロードし（場合によってはそのための仮想空間を設定する）、プログラムのためのコールスタックを設定し、そのプログラムの所定の位置に制御を渡すことで実行を開始する。
マルチタスク可能なカーネルは、ユーザーから見て実際にそのコンピュータが同時実行できるプロセス数よりも多数のプロセスが同時並行して実行されているかのように見せかける。一般に、システムが同時並行して実行できるプロセス数はそのシステムの持つCPU数に等しい。
マルチタスクシステムでは、カーネルは各プログラムにタイムスライス（そのプログラムがCPU上で実行される連続時間）を与え、プロセスからプロセスへと高速に切り換えていくので、ユーザーから見ればそれらのプロセスが同時並行して実行されているように見えるのである。カーネルは次に実行すべきプロセスを決定し、タイムスライスの長さを決定するスケジューリングアルゴリズムを持つ。一般にプロセスには優先度が設定される。カーネルはそれらのプロセス間の通信手段も提供する。これはプロセス間通信(IPC)と呼ばれ、パイプ、共有メモリ、ソフトウェア割り込みなどがある。
OSはマルチプロセッシング（SMPやNUMA）をサポートすることもある。この場合、複数のプログラムやスレッドが複数のプロセッサ上で動作する。そのようなシステムでカーネルを動作させる場合、「リエントラント（再入可能）」あるいは「割り込み可能」になるよう大幅な改造が必要となる。これはつまり、何か処理をしている最中に他からも要求を受け付けるということである。この改造ができれば、異なるプロセッサ上で動作するプログラムが同時にカーネルを呼び出しても大丈夫になる。カーネルは複数のプロセッサからのメモリアクセスを同期させる方法も提供しなければならない。これはメモリ管理とプロセス管理にまたがる問題である。
[編集] メモリ管理
- 詳細はメモリ管理を参照
カーネルはシステムの全メモリへの無制限のアクセスが可能で、ユーザープログラムの要求に応じて安全なメモリアクセスを提供しなければならない。このための第一歩はページング方式やセグメント方式による仮想アドレッシングである。仮想記憶方式では、カーネルは物理アドレスを別のアドレス、つまり仮想アドレスに変換する。これにより、各プログラムは（カーネル以外では）仮想空間上唯一のコードに見え、プログラムが互いに他のプログラムを破壊することを防止する。
仮想アドレッシング方式では、仮想空間をカーネル用の部分（カーネル空間）とアプリケーション用の部分（ユーザー空間）に分けることが出来る。この根本的な分離は多くの汎用カーネルで実際に使われている。
複数のプログラムを同時並行的に動作させるため、OSはそのシステムのメモリ容量以上のメモリを必要とすることがある。その一般的解決策は仮想記憶である。仮想記憶では、カーネルがメモリの一部を他（例えばハードディスク上のスワップファイルなど）に移し、必要に応じてメモリに復帰させる。
メモリ管理のもうひとつの機能として、カーネル内の各モジュールやデバイスドライバが使用するメモリの割り当てがある（動的メモリアロケーション）。
[編集] デバイス管理
実際に何らかの作業をするには、OSはコンピュータに接続された周辺機器にアクセスする必要があり、周辺機器はその開発元などが書いたデバイスドライバを通して制御される。例えば、ユーザーが何かを画面に表示したいなら、文字やピクセルを表示させるためにカーネルを通してモニターのドライバ（VGAとかVESA）を使用する。
デバイス管理は最初に様々なバス（PCIやUSB）上をスキャンして実装されたデバイスを検出し、対応するドライバを探す。デバイス管理は各OS固有の部分であり、カーネルの設計によってドライバの扱い方は異なるが、一般にカーネルはドライバが物理的にデバイスにアクセスするための入出力ポートやメモリ空間を用意する必要がある。デバイスへのアクセスはコンテキストスイッチを引き起こしたり、CPUを無駄に浪費したりすることになり易く、性能オーバヘッドの元となるため、デバイス管理の設計は重要である。
直接的なデバイス管理の上にファイルシステムや通信プロトコルが実装される。
[編集] システムコール
- 詳細はシステムコールを参照
意味のある作業を実行するには、ユーザープログラムはカーネルの提供する全サービスにアクセスできなければならない。これはカーネルによって実装が異なるが、多くは標準CライブラリやAPIが提供され、そこから対応するカーネル機能が呼び出される。カーネル機能を呼び出す方法は主にCPUがどのような機能を提供しているかに依存するが、ユーザーモードからカーネルモードに移行させる専用命令を使ったり、何らかのプロセス間通信機能を使ったり、例外処理や割り込みを明示的に発生する命令（トラップ命令、ソフトウェア割り込み）を使ったりする。
[編集] カーネル設計手法
上述の機能は様々な設計や実装が考えられる。モノリシックカーネルではそれらを全てひとつのアドレス空間（カーネル空間）に配置し、システムの性能を向上させようとする。マイクロカーネルはサービスの大部分をユーザー空間で動作させ、コードの保守性とモジュール性を向上させようとする[1]。多くのカーネルは明確にどちらかに分類できるわけではなく、その中間の実装とも言うべきハイブリッドカーネルになっている。さらに特殊な設計としてナノカーネルや exokernel が研究されているが、広く使われるまでには至っていない。
[編集] モノリシックカーネル
- 詳細はモノリシックカーネルを参照
モノリシックカーネルでは、全OSサービスはひとつのカーネル空間内に存在し、カーネルスレッド上で実行される。この手法は強力なハードウェアアクセスを提供する。モノリシックなシステムは設計と実装が比較的容易で、うまく書けば非常に効率がよいものになる。主な欠点はシステム構成要素間の依存関係の複雑さである。例えば、デバイスドライバにバグがあっただけでシステム全体がクラッシュするし、大きなカーネルは保守が非常に困難である。
[編集] マイクロカーネル
- 詳細はマイクロカーネルを参照
マイクロカーネルでは、ハードウェアの単純な抽象化と最小のプリミティブ（システムコール）で最小のOSサービスを実装する（メモリ管理、マルチタスク、プロセス間通信など）。他の全てのサービス（ネットワークなど）は「サーバ」としてユーザー空間に実装される。マイクロカーネルはモノリシックカーネルよりも保守が容易だが、システムコール回数やコンテキストスイッチ回数が増大するために性能が低下する傾向がある。
この問題はその後、L4プロジェクトでのプロセス間通信のチューニングなど、マイクロカーネル高速化技法の進展により解決に向かったが、マイクロカーネルにより簡略化されるはずが、高速化のために実装がより複雑になるというトレードオフも生み出した。
マイクロカーネルを採用したOSの代表的なものに、Mach、OSF/1、NeXTSTEP、Mac OS X、TRON、amoeba、chorus、Windows NT、BeOS などがある。ただし、NeXTSTEP やその後継である MacOS X、Windows NT 4.0以降については、パフォーマンス上の理由から一部のサブシステムをカーネル空間に取り込む実利的な実装を優先したため、両者とも理想的な構造のマイクロカーネルというわけではない。
[編集] モノリシックカーネルとマイクロカーネル
カーネルが巨大化するにつれて、様々な問題が明らかになってきた。最も明らかな問題はカーネルの大きさ（メモリ使用量）の増大である。これは仮想記憶をカーネル空間にも適用することである程度まで和らげられるが、全てのコンピュータ・アーキテクチャが仮想記憶をサポートできるわけではない[6]。カーネルのサイズを削減するため、不要なコードを削除するなどの改善が必要となるが、これはカーネルの各モジュール間の明らかにされていない依存関係があるために非常に困難である[7]
モノリシックカーネルが提起した問題により、1990年代の初期までにモノリシックカーネルは時代遅れと考えられるに至った。結果としてLinuxがモノリシックカーネルを採用したことでリーナス・トーバルズとアンドリュー・タネンバウムの間で有名な論争が発生した[8]。この議論では、両者の言い分にそれぞれメリットがある。
モノリシックカーネルは設計が容易で、マイクロカーネルよりも迅速に成長することが期待できる。しかし、モノリシックカーネル内のバグは一般にシステムクラッシュを引き起こすのに対して、マイクロカーネルでは一部のサーバに問題が限定される。モノリシックカーネルの支持者は、不正なコードがカーネルに無ければマイクロカーネルの利点はほとんどないと論じる。どちらの側にも成功例がある。マイクロカーネルはロボットや医療用システムで使われており、各コンポーネントが別々の保護されたメモリ空間で動作する。これは最新のモジュールロード方式であってもモノリシックカーネルには不可能であろう。モノリシックカーネルは共有型カーネルメモリを使用するよう最適化されていて、マイクロカーネルのような低速なメッセージ渡しとは異なる。
[編集] ハイブリッドカーネル
ハイブリッドカーネルは本質的にモノリシックカーネル手法とマイクロカーネルシステムの間の妥協案である。マイクロカーネルの性能オーバヘッドを削減するため一部のサービス（通信プロトコルスタックやファイルシステム）をカーネル空間で動作させるが、一部のカーネルコード（デバイスドライバなど）はサーバとしてユーザ空間で実行する。
[編集] ナノカーネル
ナノカーネルは全てのサービスをデバイスドライバとして分離する。これには例えば最も基本的な割り込みコントローラやタイマーの制御も含まれる。これによりカーネルメモリはマイクロカーネルよりもさらに小さくなる。
[編集] Exokernel
Exokernel はハードウェアを理論モデルに抽象化しないカーネルである。Exokernelは物理ハードウェア資源（プロセッサ時間、メモリページ、ディスクブロック）をプログラムに割り当てる。Exokernel上で動作するプログラムは既知のOSの抽象化を実現する「Library Operating System」をリンクして使用したり、アプリケーション固有の抽象化を行って性能を最適化することができる。
[編集] 他の設計
上述した分類に当てはまらないカーネルの設計や実装もある。AmigaOSのカーネル Exec はマイクロカーネル風である。Unununiumはカーネルを持たないOSである[9]。
[編集] カーネル開発史
[編集] 初期のOSカーネル
厳密に言えば、オペレーティングシステム（とカーネル）はコンピュータを動作させるのに必須ではない。プログラムはマシン上に直接ロードされ実行されることも可能であり、そのようなプログラムはOSのサービスや抽象化なしで記述しなければならない。多くの初期のコンピュータではそのような手法が一般的であり、プログラムを入れ替えるときにリセットとリロードが必要だった。その後、プログラムローダーやデバッガといった補助的な小さなプログラムがメモリに常駐したり、ROMからロードされるようになった。これらが初期のオペレーティングシステムのカーネルの元となった。直接実行の手法は今日でもゲーム機や組み込みシステムで使われているが、一般に最近のコンピュータではオペレーティングシステムとカーネルが使われている。
[編集] タイムシェアリングOS
- 詳細はタイムシェアリングシステムを参照
UNIX以前の10年間、コンピュータは劇的に能力を向上させ、マシンの未使用時間を使う手法が求められた。この期間の主な開発のひとつがタイムシェアリングシステム(TSS)である。TSSは何人かのユーザーがCPUのタイムスライスをそれぞれ割り当てられる。
タイムシェアリングシステムの開発は多くの問題を発生させた。ひとつの問題は大学のユーザーはCPU時間が欲しいというよりもシステムをハックしたがっているという点である。このためセキュリティやアクセス制御がMulticsプロジェクトの重要な課題となった[10]。もうひとつの問題は計算リソースの正しい扱い方である。ユーザーは計算リソースを使わずに画面を凝視することにほとんどの時間を費やしており、タイムシェアリング方式ではそのようなCPU時間を他のユーザーに与えるべきと考えられた。最終的に、メモリ階層の多層化が進み、リソースの分割が仮想記憶システムの開発へと繋がっていったのである。
[編集] UNIX
- 詳細はUNIXを参照
UNIXは数十年間のオペレーティングシステム開発の最高点を示している。設計段階では、全ての高レベルのデバイスがファイルとして抽象化されていた。何故ならUNIX設計者は情報処理の目的をデータの変換であると考えていたからである。例えば、プリンタもファイルとして抽象化され、データをそのファイルにコピーすると印字が行われる。他のシステムでは同様の機能を提供するにあたって、デバイスを低レベルに抽象化する傾向があった。デバイスもファイルも何らかの低レベルの概念の実体化である。システムをファイルのレベルで抽象化したことにより、ユーザーは既存のファイル管理機能と概念で全てを扱うことができるようになり、操作が大幅に簡略化された。同じパラダイムを拡張して、UNIXはファイルを複数の小さなプログラムで操作するパイプの概念を可能とした。最終的な結果は同じであっても、このような小さなプログラム群を使うことで柔軟性が劇的に向上しただけでなく、開発も利用も容易になった。
UNIXでは、オペレーティングシステムは2つの部分で構成される。様々な操作を実行するユーティリティプログラム群とカーネルである。プログラミングの観点から見ると両者の違いは小さい。カーネルは特権モードで動作するプログラムであり[2]、プログラムローダーとしての役割とシステムの残りの部分を構成するユーティリティプログラム群を監督する役割を持つ。そして、それらプログラムにロックと入出力サービスを提供する。つまり、カーネルはあらゆる場面に介在しているわけではなかった。
その後、計算モデルが変化し、UNIXの何でもファイルで表す手法が常に適用可能な方法ではなくなってきた。端末はファイルで表せるが（どちらも文字列を読み書きできる）、GUIはそのように扱うことはできない。コンピュータネットワークは別の問題を提起した。ネットワーク経由の通信はファイルアクセスに対応させることができるが、低レベルのパケット指向アーキテクチャはファイルというよりも離散的なデータの塊として扱う必要がある。コンピュータの機能が拡大するにつれ、UNIXのコードは増大していった。初期のカーネルのソースは10万行ほどだったが、Linuxなどでは450万行にもなっている[11]。
モノリシックカーネルの最大の問題は全体の大きさであった。コードがあまりにも膨大であるため、それを保守したり改造することは困難で時間がかかる作業となったのである。
[編集] マイクロカーネルの開発
汎用マイクロカーネルとしてはMachが有名だが、特定用途向けにもいくつかのマイクロカーネルが開発された。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時間は理論上無限だが、メモリ容量とそのアクセス速度は有限であることに注意すべきである。
- ^ デバイスドライバをカーネルの一部と見なさない考え方もあるが、例えばリアルタイムクロックなどはカーネル自身が管理する。
- ^ 仮想アドレッシングは通常、メモリ管理ユニットに内蔵された機能を使用して実現される。
- ^ そもそも何故カーネルが大きくなるとまずいのか？ 一般にOSはある程度のハードウェアシリーズで動作するが、その最小メモリサイズは最も安価なハードウェアの最小構成まで考慮する必要があり、そのようなメモリ容量でもある程度の機能が動作しなければならない。このため、少なくとも一般的な構成のカーネルがその最小メモリ容量内に収まって、アプリケーションをそれなりの性能で実行できるだけの空きメモリ容量を確保しなければならないという事情があった。最近ではメモリチップの急速な大容量化によって、このような問題は減りつつある。
- ^ ここや ここやここに議論の記録がある
- ^ Unununium OS :: Introduction
- ^ Introduction and Overview of the Multics System, by F. J. Corbató and V. A. Vissotsky.
- ^ Linux Kernel 2.6: It's Worth More!, by David A. Wheeler, 2004年10月12日。
- ^ The Fiasco microkernel - Overview
- ^ L4Ka - The L4 microkernel family and friends
- ^ QNX Realtime Operating System Overview
[編集] 関連項目
