マイクロカーネル - oraccha/omicron GitHub Wiki

マイクロカーネルアーキテクチャは，OSの巨大化，複雑化を解決するために提案された．

マイクロカーネルアーキテクチャは，OSをハードウェアを抽象化するマイクロカーネルとファイルシステムやウィンドウシステムといった様々な「機能」を提供するサーバに分割することによってOSのモジュール化を図る概念である． . そして，資源管理はサーバプロセスとして提供され，サーバごとに置き換えたり，拡張することが可能である．

このようなファイルシステムやウィンドウシステムという「機能」ブロックでシステムを構成，拡張するというモデルは分散環境を指向したMachのようなシステムでは妥当だったであろうが，パーソナルな(非常に曖昧な定義で嫌われるが)用途のシステムには別なアプローチが考えられるだろう． *例えばどんなのでしょうか？機能毎の分類はスタンドアローンでもなかなかよいと思うのですが。--有野

まず，サーバとして別アドレス空間で動作し，メッセージ通信を行なうということはオーバヘッドが問題になります． . 例えばPDAで分散OSを動作させる(将来的にあるかもしれないけど)ことよりも，データをさまざまなアプリケーションやサーバから効率的に共有したり，簡単にプログラミングできた方がメリットが大きいと思います． → 続きはPDAとマイクロカーネルへ．
そこでOS/omicron V4で考えていたのが，ワンレベルストアとデータ型に応じた資源管理の拡張でした．つまり，データ型，そしてそのデータ型に対するメソッド単位で拡張できるアプローチを採りました． *こちらはちょっとよくわからなかったです。ここでいうデータ型とはなんでしょうか？--有野
- マルチメディアデータなどの種類というか，MIMEや拡張子として表現されているようなものです． . ただし，オブジェクト指向的な拡張のアプローチとか考えてはいたのですが，結局うまくいったとは言い難いです．やはりアプリケーションのニーズを把握できてなかったなという反省があって，今はアプリケーションからトップダウンでOSを見直しているところです．って本当?
こうなるとシステムとアプリケーションの境界が曖昧になり気持ち悪いと思われるかもしれませんが...
両者の差は、セキュリティ(?)ポリシーでしかない、と例によって勝手に妄想(笑)しているんですが、どれくらい間違っているでしょうか？オイタを叱ってくれる人(=解決策の委譲先)としてシステムを期待するのがアプリで、誰も期待できない孤独な奴(笑)がシステム(カーネル)。だからこそオッカナイのでカーネルの機能(=責任)は小さくしたいよね、という話なのかなーなどと… -戯
- 両者とはシステムとアプリですか?
トカゲのしっぽ切りというか，例えばファイルシステムが死んでもカーネルは生き続けているので，セキュリティというか堅固性が高くなるというのはマイクロカーネルの利点であると思います．

初期のマイクロカーネルであるMachはこのように既存のOSの「機能」をカーネル外に追い出そうとしたが，カーネル自体はそれほど小さくならなかったし，複雑さもある意味上がってしまったと言える．

例えば，SunOS 4.1.2 のカーネルコードは 220k 行．対して，Mach 3.0 は 172k．特に仮想記憶周りのコードは SunOS が 15k で Mach が 20k と Mach の方が大きい．

Mach 3.0 以降ではデフォルトページャ(匿名メモリに対するページマネージャ)をカーネル外に追い出したりと，さらなるカーネル化が進み，メカニズムとポリシの分離ということが盛んに言われるようになった．カーネルはスケジューリング，ページングなどの基本的なメカニズムを提供するが，それをどのように利用するか，組み合わせるかというポリシはユーザレベルに任せるという設計である．

OS におけるポリシとメカニズムの分離ってのはそんなに新しい話じゃない．1975 年の SOSP には [http://portal.acm.org/citation.cfm?id=806531 Policy/mechanism separation in Hydra] って発表があった．この手の話は手を変え品を変え，何度も繰り返されるようである．
- 著者の [http://research.microsoft.com/users/roylevin/ Roy Levin] 氏って XeroxPARC から DEC，MSR と流れて行った人なんだ．王道って感じがするなぁ．

この流れをさらに押し進めたのが，拡張可能カーネルである．これらはOS全体の制御をアプリケーション側が握り，ニーズに合わせて拡張できるように設計されている．Mach ではマイクロカーネル化によるオーバヘッドが問題になったが，Exokernel や L4 は汎用的な抽象化よりもハードウェアの性能を最大限引き出すことが可能な拡張性を主張している．これには拡張性と保護のトレードオフなどの問題が伴なう．

このようなコンテクストアウェアな情報をカーネルに取り込もうという流れはあったけど，頓挫してしまった感がある．結局，OS をアプリ用に特化することでベストな解を求めるより，結局，汎用 OS を使い，アプリ側の状態をカーネルのパラメータとして扱いやすい形に落し込むことでベターな解を求めるってのが残った感じ．
大半の人はよほどのことがない限り OS に機能を追加するのではなく，アプリ側(ミドルウェアってやつ?)で解決することを選択する．まぁ，現実的ではあるし，この傾向は簡単には変わりそうにないと思う．

そして，これらはOSをコンポーネントの集合として作ろうという流れになり，MachのカーネルトレイやOSKitなどの研究が進められている． . このようなOSのコンポーネント化は組込み分野でのメリットも大きく，QNXやVxWorksなどの商用OSでも取り入れられている．ただし，組込みOSは特定のターゲットに絞り込んだり，ROM化したして利用される．つまり，動的な拡張が不要と割切られているので，コンポーネントの結合はコンパイル時に行われることが普通である．

コンポーネントのフォーマット，リンク方法を調べてみるといいかもしれない．大半は ELF などのオブジェクトモジュールフォーマットをそのまま使ってるのかな．

つまり，OS 構成法からマイクロカーネルを見たときには，Mach のようなクライアントサーバ型と，Exokernel や組込みOSといった HAL もしくは thin layer 型(?)に分類できる．

コンポーネント化みたいな話を書いてから，ずいぶん時間が経ったが，最近の流行りは Xen のような仮想化である．マイクロカーネルが廃り，VMM が受け入れられる理由は何か？マイクロカーネルと VMM は何が違うのか．HotOS X で，[http://www.usenix.org/events/hotos05/final_papers/hand.html Are Virtual Machine Monitors Microkernels Done Right?] って論文が発表されている．

OSの概念を書きながら，ちょっと考えてみた．

OS のマイクロカーネル化とコンポーネント化は直交する方向性だと思う．前者が水平型の細分化だとすれば，後者は垂直型の細分化?

モノリシックカーネルのコンポーネント化は LKM 化?
マイクロカーネルのコンポーネント化はマルチサーバ化?

    カーネル化
      ↑
      │
      │
      └──→ コンポーネント化
  モノリシック
    カーネル

カーネル化は階層化に近いイメージで，プロセッサの特権モードというレッドラインを境界にどれだけカーネルを小さくするかという話や，純粋にソフトウェア的な階層化(VFSとか)ってのが考えられる．ん〜，やっぱり後者はしっくり来ないな，境界をどこで引くかってことが本質なのかな?

カーネルとユーザアプリが分離していないモノリシックOS(?)ってのも組込みの分野にはあるわけで．

一方，コンポーネント化(部品化)は階層化も含む概念な気もするが，相互の依存の仕方が違う気もする．

マイクロカーネルに関するサーベイ論文

Andrew Tanenbaum: A Comparison of Three Microkernels, The Journal of Supercomputing, 1995. ([http://citeseer.nj.nec.com/tanenbaum95comparison.html ResearchIndex])
- Amoeba，Mach，Chorus の比較．
Margo I. Seltzer, et al: Issues in Extensible Operating Systems, Harvard University Computer Science Technical Report TR-18-97, November 1997. ([http://citeseer.nj.nec.com/171721.html ResearchIndex])