マイクロカーネル vs モノリシックカーネル
「モノシリック」は「モノシリアン(mono-syrian)のような」という意味であり、
十二世紀半ばに西欧にて発生した。
「モノシリアン」とは第2回以降の十字軍遠征を阻む、シリア(聖書でアラムの地とされる、
聖地エルサレムを含む西アジアの地中海に面する一帯の地域)の回教徒達(Syrian)の
結束したさまを指す十字軍内部で用いられていた隠語であり、十字軍衰退とともに
一般人への回教文化の流入とともに広がった。
現在、「モノシリック」は一つに統一され強固にまとまったさまを指す言葉として
用いられている。
例えばモノシリック・カーネルとは一枚岩のような丈夫なカーネルということである。 Linuxは事実上マイクロカーネルであり
マイクロカーネル VS モノリシックカーネルの結論は
やっぱりマイクロカーネルの方が良いという結論になっている。
小さいうちだけだよ。すぐに管理不能になる 同じ規模でも10人で開発するのと100人で開発するのとでは違うだろうな。 そこそこ純粋なマイクロカーネルで生きてるのってQNXとMINIX3.x位？
Windows10とかは山盛りのDLLやサービスの下にあるカーネルはマイクロカーネルだったりするのか？
UNIX系はDragonflyBSDみたいな変わり種以外はモノリシックだよね
Mac OSXは…わからん >>373
一つに固まってると力をかけるとすぐ折れるんじゃなかったっけ？ 誰でも簡単にネットで稼げる方法など
参考までに、
⇒ 『半藤のブブイウイウレレ』 というサイトで見ることができます。
グーグル検索⇒『半藤のブブイウイウレレ』
BUGPUR0KQR ☆ 私たち日本人の、日本国憲法を改正しましょう。現在、
衆議員と参議院の両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆ 2021年現在マイクロカーネルの事を語るならL4をまず調べよう
俺は最近L4の仕様書を読み始めたばかりだけどな このスレ年レベルで読む人も書く人も一桁がいいとこっぽいから俺の遊び場にしてもいいよな
>>376
IntelCPUのファームウェアに入っているという話のMINIX3よりも多く世の中に出回っているのはOKL4
一種の組み込み用ハイパーバイザだけどL4系のマイクロカーネル。これはクアルコムの通信用ICの
ファームウェア等に使われている。iOSやandroidスマホに使われているという話
年間数億台以上のレベルで使われている
>>374
「Linuxはマイクロカーネルとモノリシックカーネルの良いとこ取り」みたいなドキュメントが結構見られた時期
もあったが、それは1990年頃までの古い認識、前世紀の遺物
現在主流のマイクロカーネルでは極小原則、あるいは最小原理と呼ばれる原則に則りカーネルモード（CPUの
特権モード）で動く実際のコードサイズを可能な限り小さくする方向で実装される
L4系のマイクロカーネル実装の一つseL4（カナ書きするとエス・イー・エル・フォーと発音するとドキュメントに
書いてある）のホワイトペーパーによれば
Linuxのカーネルモードで実行されるコードサイズは2000万行、に対してseL4は1万行とされている
ここまでカーネル特権で動くコードを小さくする理由は2つ
1つは性能面の問題を解決するため
Mach等の初期のマイクロカーネルを採用したOSの性能に問題があった理由はサブルーチンコールに比べて
メッセージパッシングが遅いことだった
GHz級のクロックで動くCPUのサブルーチンコールに必要な時間は数nS程度に対してメッセージパッシングでは
平均的に数μSと1000倍程度の差があった。この時間がかかる最大の理由はプロセスAからプロセスBに通信を
行う過程でA→（カーネル）→Bとカーネルに制御を渡す必要があり、この時にキャッシュがフラッシュされてしまう
ことだった
L4開発者のリートケはメッセージパッシングを行うカーネルコードをCPUのL1キャッシュに収まる（さらに余裕がある）
程度に極小化することでこの問題が解決できることを示し、L4では数十CPUクロック程度でのメッセージパッシング
実現した
もう一つの理由はまたあとで マイクロカーネルのカーネルを小さくする（Linux比 1/1000）理由その2
安全性の点から特権モードで動くコードは最小にすべきだという思想から小さくする
2000年以降のマイクロカーネルの研究ではこちらの方がメインになっている
多くのマイクロカーネルOSではデバイスドライバはユーザ権限で動作する
従来のネットワークドライバがカーネル特権モードで動くOSの場合、そのドライバにセキュリティホールがあって外部から突くことができるとするとカーネル全体を停止させたり、最悪の場合は外部から特権を取得できてしまう
ほぼ全てのデバイスドライバがユーザモードで動くマイクロカーネルではこのような問題は起きない。例えデバイスドライバに問題があって、突くことができるセキュリティホールがあったとしてもシステム全体の特権を取得することはできない
また「発見されていない潜在的なプログラミング上の欠陥」の問題もある。2000万行のカーネル特権で動くコードを持つLinuxでは10000箇所程度の潜在的な問題があると考えられ時々セキュリティアドバイザリーとして報告される（たまにroot権限の取得が可能なものもある）
これに対して1/2000のコードサイズのseL4では存在するとしても数カ所でありroot権限の取得可能なものが存在する可能性は低い
さらにseL4の場合はマイクロカーネル全体の形式的検証が行われており問題が存在する可能性はさらに低い MacOS は原始的なマイクロカーネルOSだったMach2.5のコードを元にメッセージパッシングを行っている部分をサブルーチンコールに書き直してモノリシックカーネルにするというL4以降のマイクロカーネルとは逆方向の開発を行った物である
メッセージパッシングが遅いのが性能上の問題なのでメッセージパッシングをなくしてしまえば良いという発想である
これはマイクロカーネルの持つ利点を捨て去っているわけでMacOS10.0が開発された1990年代後半の商業用システムとしては仕方ないものだったと考えられる（当初のL4はインテルx86専用でアセンブリ言語でコーディングされている部分もあった）
もしCPUに依存しないAPIを導入したL4Ka::Pistachioの開発以降にMacOS 10.0のプロジェクトが開始されていれば違った物になっていたかもしれない ヨッヘン・リートケによるマイクロカーネルの設計方針あるいはマイクロカーネルの定義は明確である
--wikipediaからの引用--
ある概念をマイクロカーネル内で実現することが許されるのは、それをカーネルの外に移した場合、すなわち競合する実装が可能となることでシステム必須の機能が妨げられる場合だけである
この考え方に基づいてL4マイクロカーネルはわずかな基本的機構を提供する
・アドレス空間（抽象化されたページテーブルとメモリ保護の提供）
・スレッドとスケジューリング（抽象化された実行と一時的な保護の提供）
・プロセス間通信（分離された領域間の制御された通信）
---
つまりカーネルモードで実装する以外に選択肢がない物以外はカーネルに入れてはならない、という事 >>384
訂正
×Mach2.5
○Mach3.0
Mach2.5はモノリシックOSだった Mach3.0はデバイスドライバをカーネル内に実装したfatなマイクロカーネル
Mach3.0を2.5と同じモノリシックに書き換えたのがDarwinでMacOS Xのコア ここまでのまとめ
〜1990年代
OSカーネルの肥大、複雑化の反省からマイクロカーネルの概念が発生する
OSの機能を部分的にカーネルの外にユーザープロセスとして実装する試み
OSとしての機能はこの方法でも果たすことはできることが確認される
1987 MINIX1.0
1989 Mach3.0
主張：OSの開発、保守のためには小さな部分に分かれていた方が都合がいい
反論１：分割した部分間の通信にはコストがかかり性能が低下する
反論２：一つのカーネルであっても開発方針としてモジュール化はできる。開発の容易さは変わらない
1990年頃の結論：マイクロカーネルを採用する明確な利点はない 2000年前後
ドイツに天才プログラマのヨッヘン・リートケが現れる
「マイクロカーネルの実装が遅い（＝カーネルと各モジュール間の通信が遅い）のは通信によるプロセス切り替えでCPUキャッシュを使い切ってしまうのが原因である」
↓
だったらマイクロカーネルのサイズをCPUキャッシュに収まる程度の16kByte未満に押さえてしまい、メッセージの通信も高速に行える形だけに限定してしまえばいい
↓
OSの機能のほとんどをマイクロカーネルの外に実装したL4が作られる
デバイスドライバやファイルシステムもカーネルの外に実装される
性能の問題は解決した
2001年 ヨッヘン・リートケ没 惜しい人を亡くした 2000年代以降
事実：マイクロカーネルを採用しても性能は落ちない
疑問：わざわざマイクロカーネルの形でOSを構成する利点って何？
仮説１：カーネルに不具合があると不正な方法でカーネル特権を取られてしまう可能性がある。だから特権で動くカーネルはできるだけ小さい方がいい。小さければ小さいほど不具合が残っている可能性は低くなる
仮説２：デバイスやネットワーク等が原因でOSがクラッシュした場合、マイクロカーネルの外でのクラッシュであればカーネル自体は再起動せずに単一のユーザプログラムの処理だけで回復できる可能性は高い。安全性の高いOSが作れるかもしれない
このあたりが現在の研究課題
2020年代現在組み込み用ハイパーバイザとしてマイクロカーネルは広く利用されている タネンバウムとリーナスの論争なんてのは完全に1990年代の話だし、MacOS Xがマイクロカーネル実装だったMach3.0をわざわざモノリシックに書き直して作られたのは2000年頃の話でそのころのL4はCPUのアーキテクチャにゴリゴリ依存して最適化していた段階だった
だからそのあたりの話って今のマイクロカーネル技術からすれば本当の昔話
今となっては論点自体が存在しないようなお話 英語のSlideshereだけど以下の「Microkernel Evolutio」が歴史的な話から最近のMicrokernelまで扱っていて
図も多くて分かりやすい
https://www.slideshare.net/jserv/microkernel-evolution 
