「マイクロカーネル」の版間の差分

「L4」から「L4マイクロカーネルファミリー」への改名に伴う変更
m (改名による修正)
(「L4」から「L4マイクロカーネルファミリー」への改名に伴う変更)
マイクロカーネルの大規模な研究は下火になったが、研究開発は続けられた。初期のマイクロカーネル設計における性能問題の多くはコンセプトの根本的要件によるものではなく、単一用途のシステムで可能な限り多くのサービスを実装したいという設計者の願望に起因していたと見られるようになった。[[アセンブリ言語|アセンブリコード]]を使ったり、通常はソフトウェアでサポートすることをプロセッサのアーキテクチャに頼るなどして問題へのより実用的なアプローチを採用し、性能が劇的に改善されたマイクロカーネルが登場するようになった。このような新世代のマイクロカーネルを従来の多くのシステムサービスを含んだ実装と区別するため、'''[[#ナノカーネル|ナノカーネル]]''' (nanokernel) という呼称も使われた。しかし、従来型のマイクロカーネルからナノカーネルへの移行がほぼ完了すると、ナノカーネルとは呼ばれなくなっている。
 
マイクロカーネルと密接に関連する方式として{{仮リンク|エクソカーネル|en|exokernel}}がある<ref name="Liedtke_96">{{Cite journal| last = Liedtke | first = Jochen | month = September | year = 1996 | title = Towards Real Microkernels | journal = Communications of the ACM | volume = 39 | issue = 9 | pages = 70–77 | doi = 10.1145/234215.234473 }}</ref>。エクソカーネルは[[ハイパーバイザ]]と共通点が多いが<ref name="Heiser_UL_06">{{Cite journal| title=Are Virtual-Machine Monitors Microkernels Done Right? | author=Heiser, Gernot; Uhlig, Volkmar and LeVasseur, Joshua | journal=ACM SIGOPS Operating Systems Review | volume=40 | issue=1 | pages=95–99 | month=January | year=2006 | publisher=ACM | doi = 10.1145/1113361.1113363 }}</ref>、極小性を主張することはなく、[[仮想機械]]サポートに特化している。実際、[[L4]]マイクロカーネルファミリー]]はハイパーバイザの実装によく使われている。
 
== プロセス間通信 ==
IPCには同期式と非同期式がある。非同期IPCはネットワーク通信に似ている。送信側はメッセージを発行して処理を継続する。受信側はメッセージの到着を定期的にチェックするか、何らかの検出機構で通知される。非同期IPCではカーネルがメッセージ用のバッファとキューを管理しており、バッファオーバーフローもカーネルが扱う。また、メッセージは2回コピーされる(送信側からカーネル、およびカーネルから受信側)。同期IPCでは、送信側か受信側はもう一方がIPC可能となるまでブロックされる。バッファリングも複数回のコピーも不要だが、明示的に両者が待ち合わせる必要があるため、プログラミングに巧妙さを必要とする。多くのプログラマは非同期送信と同期受信を好む。
 
第一世代のマイクロカーネルは一般に同期IPCも非同期IPCもサポートしていたが、その性能は悪かった。[[:en:Jochen Liedtke|Jochen Liedtke]] はその原因がIPC機構の設計と実装にあることを示した。彼は[[L4]]マイクロカーネルファミリー|L4マイクロカーネル]]でIPCコストを10分の1以下にした<ref name="Liedtke_93">{{Cite conference| first = Jochen | last = Liedtke | title = Improving IPC by kernel design | booktitle = 14th ACM Symposium on Operating System Principles | pages = 175–88 | month = December | year = 1993 | location = Asheville, NC, USA | url = http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.40.1293 }}</ref>。IPCは送信も受信もシステムコールでサポートされ、同期式のみであり、レジスタでなるべく多くのデータを渡すようにしている。さらに Liedtke は ''direct process switch'' という概念を導入し、IPCの際に送信側から受信側へ直接(不完全な)[[コンテキストスイッチ]]を行うようにした。そのためL4では、メッセージの一部または全部をレジスタ群で渡す場合、レジスタ内のメッセージは全くコピーせずに転送することができる。さらにスケジューラを呼び出すオーバーヘッドを排除している。これは特に[[遠隔手続き呼出し]] (RPC) 的にサーバを呼び出す際のIPCに適している。もう1つの最適化として ''lazy scheduling'' と呼ばれるものがあり、IPC中にスケジューリングキューを走査せずに済むようするため、IPC中はスレッドをレディキューでブロックしたままにする。スケジューラが呼び出されると、そのようなスレッドを適当な待ちキューに移す。
 
クライアント・サーバ型システムでは多くの通信が基本的に同期式であり、非同期なプリミティブを使っていたとしても、通常はクライアントがサーバを呼び出し、応答を待つことになる。その方が実装も効率的になるため、L4以降のマイクロカーネルでは同期IPCプリミティブのみを提供するようになった。非同期IPCは補助スレッドを使って同期IPCプリミティブ上で実装できる。しかし、L4を採用した商用製品では非同期通信サポートのために非同期通知機構が必要であることが判明し、それを追加している。この[[シグナル (Unix)|シグナル]]のような機構はデータを転送するものではなく、カーネルによるバッファリングが不要である。
効率化のため、ほとんどのマイクロカーネルはスケジューラとタイマー管理を含んでおり、極小原理と機構と方針の分離の原則に反している。
 
マイクロカーネルを使ったシステムの立ち上げ([[ブート]])では、カーネル内に含まれない[[デバイスドライバ]]が必要になる。一般に必要なデバイスドライバをカーネルと共にパッケージ化してブートイメージを作成する必要があり、カーネルはデバイスドライバを配置して起動する手順をサポートしている必要がある。例えば[[L4マイクロカーネルファミリー|L4]]ではそのようなブート方式になっている。一部のマイクロカーネルは重要なデバイスドライバを(極小原則に反して)カーネルに含めており、[[LynxOS]]や元々のMINIXが挙げられる。ブートを単純化するため、[[ファイルシステム]]までもカーネルに含める場合がある。[[マルチブート]]対応のブートローダからブートできるマイクロカーネルのシステムもある。その場合、静的リンクされたサーバ群をロードするか、OSイメージをマウントすることで立ち上げを続行する。
 
マイクロカーネルにおいては、[[プロセス間通信|IPC]]システムと仮想記憶管理の設計が重要であり、[[ページフォールト]]処理やスワッピングをユーザーモードのサーバで安全に実装できるようにすることが肝要である。全サービスがユーザーモードのプログラムで実行されるので、それらプログラム間の効率的通信手段が必須である。これはモノリシックカーネルに比べて遥かに重要である。効率化するには、IPCシステムのオーバーヘッドを小さくするだけでなく、CPU[[スケジューリング]]ともうまくやりとりしなければならない。
多くの主流のプロセッサにおいて、サービスを得るのにかかるコストはモノリシックカーネルよりもマイクロカーネルの方が本質的に高い<ref name="Liedtke_96"/>。モノリシックなシステムでは、サービスを得るのに1回の[[システムコール]]を使用し、その際に2回の「モード切り換え」(プロセッサの[[リングプロテクション|リング]]または[[CPUモード]]の変更)を必要とする。マイクロカーネルを採用したシステムでは、サービスを得るにはサーバにIPCメッセージを送り、別のIPCメッセージで結果を得る必要がある。このときドライバがプロセスとして実装されていれば[[コンテキストスイッチ]]が必要であり、プロシージャとして実装されていれば関数呼び出しが必要である。さらに実際にデータをサーバに渡して結果のデータを戻してもらうには、データをコピーするオーバヘッドが余分にかかる。モノリシックカーネルでは、クライアント(ユーザー空間)の持つバッファにあるデータに直接アクセス可能である。
 
したがってマイクロカーネルシステムには性能問題が潜在している。実際、[[Mach]]や[[ChorusOS]]といった第一世代のマイクロカーネルを採用したシステムの性能は低かった<ref name="Chen_Bershad_93">{{Cite conference| first = Bradley | last = Chen | coauthors = Bershad, Brian | title = The Impact of Operating System Structure on Memory System Performance | booktitle = 14th ACM Symposium on Operating System Principles | pages = 120–33 | month = December | year = 1993 | location = Asheville, NC, USA | doi = 10.1145/168619.168629}}</ref>。しかし [[:en:Jochen Liedtke|Jochen Liedtke]] はMachの性能問題は設計と実装がまずかったためであることを示し、特にMachが{{仮リンク|ページキャッシュ|en|page cache}}を使いすぎていることを指摘した<ref name="Liedtke_95"/>。Liedtke は自身の[[L4マイクロカーネルファミリー|L4マイクロカーネル]]を注意深く設計・実装することで、特に極小原則に従えばIPCコストをMachの10分の1以下にできることを証明した。L4のIPC性能は様々なアーキテクチャ上で最速を誇った<ref name="Liedtke_ESHHIJ_97">{{Cite conference| first = Jochen | last = Liedtke | coauthors = Elphinstone, Kevin; Schönberg, Sebastian; Härtig, Hermann; Heiser, Gernot; Islam, Nayeem; Jaeger, Trent | title = Achieved IPC performance (still the foundation for extensibility) | booktitle = 6th Workshop on Hot Topics in Operating Systems | pages = 28–31 | publisher = IEEE | month = May | year = 1997 | location = Cape Cod, MA, USA | url = http://os.ibds.kit.edu/65_987.php}}</ref><ref name="Gray_CCMH_05">{{Cite conference |first=Charles |last=Gray |coauthors=Chapman, Matthew; Chubb, Peter; Mosberger-Tang, David; Heiser, Gernot |title=Itanium&mdash;a system implementor's tale |booktitle=USENIX Annual Technical Conference |pages=264–278 |date=April 2005|location=Annaheim, CA, USA |url= http://www.usenix.org/publications/library/proceedings/usenix05/tech/general/gray.html}}</ref><ref name="vanSchaik_Heiser_07">{{Cite conference| first = Carl | last = van Schaik | coauthors = Heiser, Gernot | title = High-performance microkernels and virtualisation on ARM and segmented architectures | booktitle = 1st International Workshop on Microkernels for Embedded Systems | pages = 11–21 | publisher = NICTA | date = January 2007 | location = Sydney, Australia | url = http://www.ssrg.nicta.com.au/publications/papers/vanSchaik_Heiser_07.pdf | accessdate = 2007-04-01}}</ref>。
 
そういった結果により、第一世代のマイクロカーネルの性能の低さは第二世代のL4などのマイクロカーネルには当てはまらないことを示したが、マイクロカーネルをベースにしたシステムが高性能を発揮できることを証明したわけではなかった。それでもモノリシックなLinuxサーバをL4上に移植したものは、通常のLinuxに対して数パーセントのオーバーヘッドを示しただけだった<ref name="Hartig_97">{{Cite journal| first = Hermann | last = Härtig |
83

回編集