Machに関する世界観です。
ファイルシステムやデバイスドライバのようなユーザーランドに近いカーネルの機能を、モノリシックカーネルでは一番下の巨大なカーネルの一部として実装するが、マイクロカーネルではユーザー空間で動く「サーバ」として実装する。このことによって、カーネルは小さく（マイクロ）になり、それぞれの個別のサーバはアプリケーションとして動かすことができる。
Linuxではカーネルの一部としてファイルシステムやデバイスドライバを実装しているが、Machなどではカーネルは最低限のプロセス管理やメモリ管理やIPCだけを行い、サーバによってファイルシステムなどが実現されている。
マイクロカーネルの優位性はいくつかある。
まず、マイクロカーネルでは、必要のない機能はサーバを停止するだけでいつでもON/OFFできる。そのため、ファイルシステムやネットワークなどが必要ない組み込みシステムやリアルタイムOSでは、大きなメリットになる。
それから、メモリ管理の効率が良い。全てのカーネル機能をメモリに置かず、必要になった段階でサーバーを起動すれば良いため、効率的なメモリ管理ができる。
デメリットとしては、カーネルの設計が複雑になる。特に、スレッドやポートを用いてメッセージによるタスクの管理を行うMach/Hurdのモデルは、設計上複雑すぎて、きちんと動かない。動作速度も遅く不安定になる。
こうしたデメリットについては、L4のように、「注意深く設計することで高性能なIPC性能をたたき出す」というマイクロカーネルも誕生している。
逆に、サーバのON/OFFやメモリ効率性のメリットについては、Linuxや*BSDなどはモジュールによってカーネルにいつでも機能を組み込むことができるようにすることで、モノリシックカーネルでも可能となる。
GNU Hurdがなかなか完成しなかったことについて、ストールマンは「マイクロカーネルのデバッグが予想以上に難しかった」という点を挙げており、サーバーとユーザーランドのプロセスが相互に通信し合うマイクロカーネルの設計は、デバッグや開発も難しい。
Machでは、タスク、スレッド、ポート、メッセージ、メモリオブジェクトによるマイクロカーネルを実現する。
僕のイメージとしては、それぞれのタスク内のスレッドがポートに対してメッセージを送るような形になるのかもしれない。Hurdのロゴのようになる。
後日注記：要するに、プロセスとメモリを分離し、別々のタスクのスレッドからメモリにアクセスできるようにした上で、ポートに対してメッセージをやり取りすることでプログラムを構築する。メモリオブジェクトと仮想記憶の管理はユーザー空間に開放され、同時にネットワークなどの状況にもメッセージとポートが新しい通信経路となって対応する。
Machはカーネギーメロン大学のリチャード・ラシッド教授によって開発され、Mach 3.0までリリースされたが、その後はユタ大学のMach 4プロジェクトや、FSFでのMach 4をベースにしたGNU Machとして開発・公開されている。
GNU MachはGNU Hurdでのマイクロカーネルとして採用されている。
ソースコード
L4を参照のこと。
僕は、MachのようなマイクロカーネルOSの問題とは、カーネルを小さくすることで、単純なシステムにできるかもしれなかったにもかかわらず、それをせずに、複雑で高度なシステムにしてしまったことだと思います。
マイクロカーネルとは、文字通り「小さなカーネル」あるいは「必要最小限のカーネル」という意味です。
モノリシックカーネルとは、「一枚岩の巨大なカーネル」という意味です。
そう、文字通りの意味でいえば、シンプルなのはマイクロカーネルのほうだったはずなのです。
マイクロカーネルにすることで、カーネルの中のカーネル内にある必要のない機能は、すべてカーネルの外に追い出して、カーネルは最低限の処理だけを行えばよかったはずです。
マイクロカーネルは、上手くモジュール化して、プロセスを分離することで、モノリシックカーネルのように、今稼働中のシステムにとって不要であるはずの機能をすべて読み込まず、シンプルなシステムを実現できるはずです。
システム全体から見ても、プロセスやサーバーにカーネルの機能を明け渡すことで、さらにユーザーランドのプログラムも、シンプルで単純なシステムの上で動くはずです。
Machのように、高度で複雑なマイクロカーネルOSというのは、僕は本来のマイクロカーネルではないと思います。よりシンプルで、L4のように上手く設計されたマイクロカーネルOSが開発されれば、UNIXの肥大化したカーネルをスリムにし、システムをシンプルにするような、そのような「今のマイクロカーネルの反対のマイクロカーネルOS」を作ることができると思います。
2023.01.30