マイクロカーネル vs モノリシックカーネル
一度本気で語ってみたい題目。リーナスvsタネンバウムで
いろいろネタは出てるが、時代は変わっている。もう一度
語ってみようじゃないか。
・性能の違い
・実装の違い
・リーナスとタネンバウム
何でもいいので語ろう。 そもそもAppleには開発力がないためにOSの開発に失敗して、
他からカーネルを借りてきた。
MacOSは〜と自慢気にいう馬鹿はなんなのだ。 でっていう。
Darwinの何割が借り物なのか定量的に言わなきゃ、どっちも知らんがな。 むしろ、借り物ってのがステマだったってことはないだろうか?
Copelandは締切りに間に合わなかったけど秘密裏に開発成功していて、
でも今更どうしようかって時に、売れないのに評判だけはよかった同系の
NeXTの技術を導入したということにして汚名返上してみたとか? 妄想してみるなら、例えばGPL汚染が内部調査で発覚して、
結合しているブラックボックスは公開するわけにはいかなかったので、
密かにロンダリングしてたというのはどうだろう?
従来の延長路線でAPIを整理しつつ、linuxの名前を利用し汚染部分を公開して
その外部GPLコードの内製置き換えをテストさせていたとかは考えられないだろうか? NSってプレフィックスが付いてるものはNeXTSTEP由来と思えばいいんじゃねーの?
Mac信者というかジョブズ信者にとってはOS XとNeXTSTEPはおんなじようなもののようだし。 mach2.5同士が合致しないと言われて、mach3がおんなじようなものと言われる不思議。 Darwinってmach3系だっけ?
NextStep由来なら2.5系じゃないの? 最初の奴だけ2.5で、その後何故か3になってるんだっけ?
マイクロカーネルでもないのに何の意味があったんだろう? 人とゴリラの遺伝子は98.25%合致するらしいから、誰かが1.75%をでっち上げれば
ゴリラをandroid化できるな。 Hurdっていつでるの?
あと、なんでマイクロカーネルにGnuはこだわるの?
Hurdはもうあるんじゃない
これ以上のものはもうでてこないんじゃない
GNUはマイクロカーネルにこだわっていないんじゃない
すでにLinuxを我が物顔で「GNU/Linux」と呼べとか行ってるし マイクロカーネルにこだわってたというより、当時はフリーな選択肢がそれしかなかったんじゃないの?
machはOSF陣営が採用していたわけで、UNIXとしての実績があった。
3でマイクロカーネル化してOSコアのmach部分とライセンスが必要な部分が分離できていた。
というわけで後者の代替を作ろうと考えたんじゃない?
でもBSDが、いやよく考えてみたら気がついたらこれ殆ど原型とどめてなくね?
ってことでフリーでいいよとNet/2を出して、いやそれおらんだってことで裁判沙汰になって
FreeBSDなんか書き直しする羽目になったけど、それでもHurdより先にリリースできて、
その少し前に現れたlinuxに人が集まって、その間にUNIXの冷戦構造も崩壊して、
情報ハイウエイやら、PCはdosからwindowsの時代になるわで、大事な数年を逸して、
一体なにもたもたやってんのさ?って事になったんじゃないんだろうか? ライセンスに縛られないUNIXとしては(訴訟期間はあれど)BSDがとっくに良いものをリリースしていたのに
それでもGPLにこだわって「GPLのカーネル」を欲するのがGNUたるゆえんかな
Gnu is Not UnixはUNIXに代わるフリーなシステムを作る事ではなくUNIXに代わるGPLのシステムを作る事だったと >>344
いや、Net/2はLinux 0.01と同じ年で、その前年からHurdは開発始まってたらしいよ。
しかしブートできるまでに3年も掛かって、その頃にはSoundBlasterで
CD-ROMが普及していたので、リリースした時点であっという間に広まった。
逆に言えばライセンス問題があるとCDプレスに二の足を踏むわけで、
破棄だけは避けようと譲歩したんじゃないんだろうか?
まあ4.4BSD Liteベースで完全解決できた訳だけど、その隙にlinuxが入り込めた。
せめてLite移行完了までにHurdが形になっていれば、真打ち登場と言えたんだろうけど、
mklinuxとか、linuxにさえ抜かれちゃう始末だし。
mach3はGPLではないので(HurdもGNU Machの機能は使っていないんだっけ?)
GPL以外に代替があるなら完成度の低いものをわざわざ選択する意味はないよね。 しかしBSD on muchって何度も復活するよね
初代much(これは不完全だが) > Hurd? > dragonfly BSD
でも普及には至らないんだよなぁ
一応、NextとOSF/1は実用か? っていうか、ttp://www.rtmach.org/intro-j.html
こんな面白そうなものがあったのに誰も紹介しないんだもん。
存在知らないから独自OSに走って車輪付けるところで消耗して結局エターナる
OS開発者も居たんじゃないだろうか?と、androidの作りとか見て思った。 10年位前から知ってるし
独自OS作る奴は作ることを楽しんでいるんだから既存のOSはあまり関係ないだろう
逆に既存OSより良いもの(実用的な物)が欲しい奴は見込みの有りそうなプロジェクトにコミットしてるんじゃない? >>348
>10年位前から知ってるし
それをどうやって証明するのさ?
消息不明の作者逹にアンケートでもした?
>独自OS作る奴は作ることを楽しんでいるんだから既存のOSはあまり関係ないだろう
そういう思い込みで教えてもらえなかった連中も多いんじゃないの?
誰でも知っているような事を意外と知らなくて遠回りしたなんて話も後で結構聞くんだよな。
まあ困ってる事をきちんと言わない見栄っぱりの自業自得だけど。 >>10年位前から知ってるし
>それをどうやって証明するのさ?
>消息不明の作者逹にアンケートでもした?
10年は嘘だった
このページで知ったから5〜6年前だ
http://www.bekkoame.ne.jp/ha/kuwaya/unchiku.html
各作者が知ってるかどうかは知らんし、そういう文章にはなってないはずだが?
>>独自OS作る奴は作ることを楽しんでいるんだから既存のOSはあまり関係ないだろう
>そういう思い込みで教えてもらえなかった連中も多いんじゃないの?
なら俺OS系のWikiとかに書きこんでみたら?
その考えのほうが思い込みだってわかると思うよ 何が思い込みなんだ?
俺OS(だと思い込んでるの)にわざわざ別のOSの事言う奴はアンチだけってことだろ。
顰蹙を買うのは嫌なので(悪)名を売りたいのでなければ黙っていた筈。
「あまり関係ないだろう」と書かれていて、そう思っている人が居るのは事実で、
そういう人は指摘してくれないだろうから、後は2chでも見るしかないんじゃないか? 既存の有無というのは、モチベーションの面で関係大アリじゃないかな?
無いのでオレが作りたいと思う奴は、有ると知ったらやめたくなる。
有るので真似すれば作れると思う奴は、無いと知ったら逃亡する。 アジア人は全体を見て行動し、西洋人はリーダーを見て行動するらしい。
これってマイクロカーネルとモノリシックカーネルの考えそのものじゃないだろうか?
でも実際の区分はぶっちゃけ、ランプの魔神を大衆の願いを叶えてくれる仏のようなお上と考えるか
市民の下で働く一騎当千の公僕と考えるかという違いの話になってるんだよね。
結局、文民統制にハードウェアによるカーストを利用するかどうかで、
性悪説なら緊箍児が必要だし、性善説なら不要って話に矮小化されちゃってる。 ドライバーに対してはスタックマシンとして振る舞うVMスタブが一番堅牢。
VMのサーフェス側のサービスレベルをどの高さに設計するかだけの話。
と言うのも、どうしてもソフトウェアカーネルを設置したいのであれば、あれこれ調整された機能の調製を求める内にモノリシックに行き着くのは当然であるから。
しかし、そもそもソフトウェアカーネルなんぞハードウェアの仕様を覚えられない難読症児の戯言だとする者はマイクロカーネル乃至マイクロコードを指向する様になる。
最速は常にハードウェア、以上。 amiga osはマイクロカーネルだったのか
「マイクロカーネル風」って表現もあるし、メモリ保護なし・直接関数コールとかスゲーけど別にいいよね
あとMacOS9の下にマイクロカーネルがあったのも知らんかった マイクロカーネルもバズワードで明確な定義が無いのだから風も何もない。 基本的には「プロセス/ファイルシステムやデバイス・ドライバー等の大きな機能を除いた基本機能のみ」のカーネルって事だけど
・基本機能とは?(タスクスケジューラーやメモリアロケータも含まない!とか仮想アドレス+メモリ保護も必要!)
辺りの解釈が不明確というか各人で分かれてる感じ
スケジューラーとメモリアロケータは含まないけどメモリ保護は必須みたいな意見も見た気がするし・・・ メッセージパッシング機能とディスパッチャが最低限でしょ。 メッセージパッシングの方式(amigaは関数テーブル呼び出しだそうで)をどう定義するか
他の機能(スケジューラーやメモリ管理)がのっているものはマイクロカーネルじゃない!と原理主義に走るか(ゆるくし過ぎるとなんでもかんでもマイクロカーネルと言えるようになるし)
線引は難しいですよね CISC RISC
と一緒で完璧にどちらかに分類できる実装なんか今時存在しない 質問です
マイクロカーネルについて勉強中です
マイクロカーネルはプロセス間通信を使用してサービスを受けると理解しました。
これはアプリがシステムコールを呼んだ際、自分のコンテキストは待ち状態になり
サーバーで待ち状態だったプロセスが解除されてコンテキストがバトンタッチ(?)するという感じでしょうか?
もしそうならば、たとえばサーバーのプロセス(スレッド)が1つしかない場合、複数アプリから同時にサービスコールが呼ばれると
1つだけ処理されて、残りは待たされるのでしょうか?
あいまいな質問ですみません。 YES
物理ディスクのアクセス等は(キャッシュ等は除き)そもそも並列動作できないから普通に待ち行列行き
OS機能全体を1つのスレッド(プロセス)で処理するような実装なら誰かがシステムコールを実行中は他は待たされる
たいていはサービス毎に処理スレッド(プロセス)を走らせるから競合しなければ並列動作する(ディスクIOとコンソール出力とか…) マイクロカーネルばんざーい!
マイクロカーネルとして良いのはなんだろう
L4? QNX? MINIX? OSE?
OSの話題が無くてつまらん
モノリシックはNetBSD最高 最新の Minix は マイクロカーネル + NetBSD だし はい…
それはそれとして本家NetBSDの移植性を高めた設計も好き 一時期モノリシックカーネルの方が正義みたいな扱いだったけど
またここに来てマイクロカーネルの方に勢いが出てきたつーか研究が盛んだね
次スレ立てるときはハイブリッドカーネルも入れてくれ 最近ワンボードPCを買ったからとりあえずseL4で遊ぼうと思う。 「モノシリック」は「モノシリアン(mono-syrian)のような」という意味であり、
十二世紀半ばに西欧にて発生した。
「モノシリアン」とは第2回以降の十字軍遠征を阻む、シリア(聖書でアラムの地とされる、
聖地エルサレムを含む西アジアの地中海に面する一帯の地域)の回教徒達(Syrian)の
結束したさまを指す十字軍内部で用いられていた隠語であり、十字軍衰退とともに
一般人への回教文化の流入とともに広がった。
現在、「モノシリック」は一つに統一され強固にまとまったさまを指す言葉として
用いられている。
例えばモノシリック・カーネルとは一枚岩のような丈夫なカーネルということである。 Linuxは事実上マイクロカーネルであり
マイクロカーネル VS モノリシックカーネルの結論は
やっぱりマイクロカーネルの方が良いという結論になっている。
小さいうちだけだよ。すぐに管理不能になる 同じ規模でも10人で開発するのと100人で開発するのとでは違うだろうな。 そこそこ純粋なマイクロカーネルで生きてるのってQNXとMINIX3.x位?
Windows10とかは山盛りのDLLやサービスの下にあるカーネルはマイクロカーネルだったりするのか?
UNIX系はDragonflyBSDみたいな変わり種以外はモノリシックだよね
Mac OSXは…わからん >>373
一つに固まってると力をかけるとすぐ折れるんじゃなかったっけ? 誰でも簡単にネットで稼げる方法など
参考までに、
⇒ 『半藤のブブイウイウレレ』 というサイトで見ることができます。
グーグル検索⇒『半藤のブブイウイウレレ』
BUGPUR0KQR ☆ 私たち日本人の、日本国憲法を改正しましょう。現在、
衆議員と参議院の両院で、改憲議員が3分の2を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆ 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の開発、保守のためには小さな部分に分かれていた方が都合がいい
反論1:分割した部分間の通信にはコストがかかり性能が低下する
反論2:一つのカーネルであっても開発方針としてモジュール化はできる。開発の容易さは変わらない
1990年頃の結論:マイクロカーネルを採用する明確な利点はない 2000年前後
ドイツに天才プログラマのヨッヘン・リートケが現れる
「マイクロカーネルの実装が遅い(=カーネルと各モジュール間の通信が遅い)のは通信によるプロセス切り替えでCPUキャッシュを使い切ってしまうのが原因である」
↓
だったらマイクロカーネルのサイズをCPUキャッシュに収まる程度の16kByte未満に押さえてしまい、メッセージの通信も高速に行える形だけに限定してしまえばいい
↓
OSの機能のほとんどをマイクロカーネルの外に実装したL4が作られる
デバイスドライバやファイルシステムもカーネルの外に実装される
性能の問題は解決した
2001年 ヨッヘン・リートケ没 惜しい人を亡くした 2000年代以降
事実:マイクロカーネルを採用しても性能は落ちない
疑問:わざわざマイクロカーネルの形でOSを構成する利点って何?
仮説1:カーネルに不具合があると不正な方法でカーネル特権を取られてしまう可能性がある。だから特権で動くカーネルはできるだけ小さい方がいい。小さければ小さいほど不具合が残っている可能性は低くなる
仮説2:デバイスやネットワーク等が原因でOSがクラッシュした場合、マイクロカーネルの外でのクラッシュであればカーネル自体は再起動せずに単一のユーザプログラムの処理だけで回復できる可能性は高い。安全性の高いOSが作れるかもしれない
このあたりが現在の研究課題
2020年代現在組み込み用ハイパーバイザとしてマイクロカーネルは広く利用されている タネンバウムとリーナスの論争なんてのは完全に1990年代の話だし、MacOS Xがマイクロカーネル実装だったMach3.0をわざわざモノリシックに書き直して作られたのは2000年頃の話でそのころのL4はCPUのアーキテクチャにゴリゴリ依存して最適化していた段階だった
だからそのあたりの話って今のマイクロカーネル技術からすれば本当の昔話
今となっては論点自体が存在しないようなお話 英語のSlideshereだけど以下の「Microkernel Evolutio」が歴史的な話から最近のMicrokernelまで扱っていて
図も多くて分かりやすい
https://www.slideshare.net/jserv/microkernel-evolution