マイクロカーネル vs モノリシックカーネル

**Be名無しさん** · NG

一度本気で語ってみたい題目。リーナスvsタネンバウムで
いろいろネタは出てるが、時代は変わっている。もう一度
語ってみようじゃないか。

・性能の違い
・実装の違い
・リーナスとタネンバウム

何でもいいので語ろう。

**Be名無しさん** · NG

おいおいおい・・・2getかよ

2 · NG

初2getｷﾀ━━━(ﾟ∀ﾟ)━( ﾟ∀)━( ﾟ)━( )━(ﾟ )━(∀ﾟ )━(ﾟ∀ﾟ)━━━!!!!!

**Be名無しさん** · NG

このスレはマジに語れるのか？？？？？？

**Be名無しさん** · NG

>>3
晒し上げ

LC · NG

マイクロカーネルが、モノリシックカーネルより、いくつかの点で
「よい」とか言う主張だって、いい加減さは同じだよ。

良いというならば、具体的に数値化して示さなきゃ、学問ではない。

論理的に帰結を得られないならば、実測でもいいが、そのどちらも
書かずに、「よい」とか「悪い」とか書いたんでは、科学じゃない。

物理学などは、大学での研究が信頼性はかなり高いと思う。なぜなら、
全部理詰め、論理、数式などで精密に導いているから、実験を全く
しなくても、ほとんどの場合、正しい結果を得られる場合が多いと
考えられるから。

しかし、今の日本の工学の教科書みたいな論理(?)の進め方だと、
実験もロクにしていない癖に、精密な論理も用いてないので、
高頻度で間違いが入ってしまう。

実際、大学の試験で間違ったことを書かせることさえ、あり得るのでは
ないかと思ってしまう。

つまり、主観をテストで問うようなことがあり得ると言うこと。

こんなものを、学生にイレジエしては困る。

大学教育が進めば進むほど、日本の技術が間違った知識が蔓延したりね。

現場で実際にやってみると、間違ってたら動かないので気付くんだけど、
工学を馬鹿真面目にやってるだけでは気付かずに、馬鹿知識蔓延するよ、
まじで。

4 · NG

組み込み向けにはマイクロカーネルがいいと思われ
モノリシック＆モジュールは便利だが、モジュールがこけると
カーネルごとこけるのがいただけない

LC · NG

前にも書いたと思うけど、Tanenbaum教授は、マイクロカーネルを
信奉している人。一方、Linusは、マイクロカーネルに大した価値を
見出さない人で、むしろ、モノリシックカーネルを信奉している人。

この二人の意見は真っ向から対立する。

世界的にも、工学の教科書では、どうやら、「マイクロカーネル」の
方が次世代の形態で、「よい」とされているようだが、しかし、
教科書を書いた人の何割が、それを深く理解しているのだろうか。

実際問題、商用UNIXでも、マイクロカーネルに移行する機会があったの
にもかかわらず、速度パフォーマンスの面などを考慮した結果だと
思われるが、結局、採用されなかった。

マイクロカーネル代表の、Machでも、Minixでも、いろんな問題を
含んでおり、未だ解決されていない。

実際にOSを作っている人たちには、モノリシック派は、かなりの割合で
存在しているように思える。しかし、恐らくだが、他人のOSを研究したこと
はあっても、自分で作ったことはないであろう人が書いたOSの教科書
には、マイクロカーネルが賛美されてしまっている。

一見、事情を知らない人、例えば政府役人などが見れば、大学研究者
の方が、頭もよくて、最先端の知識があるから、現場の
「デジタル・ドカタ」であるところの、プログラマの言うことが
間違いで、大学研究者の方が正しいと見なしてしまい、ちゃんと
勉強して出直せと命じてしまうだろう。

しかし、実体はそうではないと思うのだ。

**Be名無しさん** · NG

> 実際問題、商用UNIXでも、マイクロカーネルに移行する機会があったの
> にもかかわらず、速度パフォーマンスの面などを考慮した結果だと
> 思われるが、結局、採用されなかった。
Solarisより遥かに頑丈なTru 64 UNIXを知らんのだな。
OSF-1から連綿と続く系統なんだが。

1 · NG

Machは複雑になりすぎてるという論調はあるみたいだが、OSの研究
としては高く評価されているのでは？

**Be名無しさん** · NG

> Solarisより遥かに頑丈なTru 64 UNIXを知らんのだな。
> OSF-1から連綿と続く系統なんだが。
HP-UXへ統合という名目で葬られましたが何か？
セットだったAlphaもItaniumへ統合って名目で葬られたしね。
で、結局Mach出身でシェアトップなのはOS Xだね。

∴Darwin <<<<<<<<<<<<<<< HP-UX <<<<<<<<<<< Tru64 <<<<<<<<<<<<<<< Solaris
<<<<< *BSD <<<<<<<<<<< (超えられない壁） <<<<<<<<<<< 犬糞

**Be名無しさん** · NG

確かに理論だけでは語れない部分が多々あるのは確か。
実際に日本でOSの開発をしている開発者はどう思うので
しょうかねぇ

LC · NG

マイクロカーネルの例として、Minix, Mach, WindowsNTについて。

Minixは、マイクロカーネルだが、MMUを使っておらず、保護が全くない
(と思う)。また、教材用のため(というか、学者が作ったOSで、学者は
そういうことを理由にしがちなのだけど）、遅いらしい（MMUを使わずに
マイクロカーネルにするという、意味不明なことをやっていて、個人的に
は方針が見えない。MMUなしのOS作りは、MMUありよりかなり簡単なので、
余り勉強にならず、教材としても余り意味がないかも。）

Machは、高速化するために恐ろしく難しくなっているというLinusの
コメントがある。マイクロカーネルの当初の目的は、作りの単純さに
あったはずなので、本末転倒だと言えるのではないか。

WindowsNTは、ネットでの資料によれば、比較的高速らしいが、真偽
のほどはよく分からない。速度測定や比較は、やり方を適切にして、
考察を正確に行わなければ正しいことは言えないので、余りネットや
雑誌の資料は当てにならない。実感として特に遅い事はないと思うが、
WindowsNT系は、Windows9x系よりも明らかに遅いことは事実。
よって、このケースでもマイクロカーネルの方がやはり遅い。
しかも、遅さも無視できる程度ではない。

LC · NG

Minixで、MMUを使わずにマイクロカーネルを採用する意図が、私には全く
理解できない。

MMUを使わなければ、そもそもデータ保護ができない。

そもそも、「カーネルモード」と「ユーザーモード」の区別がなく、
また、別のタスクのメモリを簡単に読み書きできてしまう。

そもそも、OS作りで大変なのは、保護をしたいからこその複雑さ。
保護しなくて良いなら、ずっと簡単に書けてしまう。
マイクロカーネルにしたところで、保護しやすくなるわけはない（保護
がそもそもできないのだから。）。

マイクロカーネルの遅さの１つは、メモリ空間が異なるバッファ間のコピー
にある。MMUを使って保護目的にメモリ空間を故意に分離しているのだから、
普通にmemcpy()で済ませられず、通常、ページテーブルを書き換えて、
アドレス変換マッピングを変更する必要がある。

しかし、MMUを使わないなら、memcpy()で済ますことができるから、
この遅さは有り得なくなる。

よって、MMUを使っていないところの、Minixが仮に遅くないとしても、
マイクロカーネルの速度に関しては、何の根拠にもならない。

LC · NG

保護するために複雑になる例 : メモリ確保

保護なしで済む例:malloc()関数。
malloc()関数は、確保したメモリブロック
の前後にヘッダを持つ。ユーザープログラムに間違いがあると、そのヘッダ
情報が破壊され、ヒープメモリシステム自体が崩壊する。
しかし、崩壊は、そのタスク内で留まる。

保護有りの例:保護機能を持つOSのシステムレベルでのメモリ確保
メモリブロックのヘッダ情報を、保護ページに格納することで、
アプリケーションが破壊することができないようになっている。
しかし、構造上、メモリブロック本体とヘッダの二種類が存在する
ことになり、適切に組まないと、メモリ空間を全部使い切ることが
できなくなったり、物理メモリ容量が余っているのに、ブロックの個数
制限があって事実上メモリ不足のようになってしまうことになるかも
しれない。前述のmalloc()に比べるとアルゴリズムが難しい。

LC · NG

一応念のため:「マイクロカーネル」とは、ファイルシステム、タスクロード、
GUIシステムなどのOSの基本機能を、「タスク(プロセス)」にほぼ等価な形態で
実装する方式のことを言います。

次の理解は間違いです:

1. モジュール化したOSをマイクロカーネルという」
2. OSの一部をユーザーモードで実行できるようなものをマイクロカーネルという

1. については、多くの方が理解されているようですが、2.については誤解が
多いようです。

CPUの種類によっては異なるかも知れませんが、基本的には、特権レベルと
タスク(プロセス)は、概念が全く別で、タスクはメモリ空間の分離単位
ですが、ユーザーモードかカーネルモードは、特権レベルの違い、つまり、
保護上の差でしかありません。

従って、本当のタスク(プロセス)にしなくても、ファイルシステムをユーザー
モードで動かすことは可能です。

わかりやすく言えば、システムコールを、呼び出し元のタスクと同じメモリ
空間で実行する形態をモノリシックカーネル、メモリ空間を切り替えてから
実行する形態がマイクロカーネル、と言うことになると思います。

例えば、read()コールを発行すると、モノリシックなら、キャッシュに載って
いれば、タスク切り替えなしで単にmemcpy()で済むでしょうが、
マイクロカーネルならば、必ずFSのタスクに切り替わる必要があると
思います。

LC · NG

参考:

Linuxの作者もマイクロカーネルの弱点を指摘:
http://www.linux.or.jp/JF/JFdocs/linus-lecture/monolithic.html

Mach:マイクロカーネルへ移行していくと速度低下が見られたため、モノリシック
に戻さざるを得ない状況になったが、未だこの欠点は克服されておらず、
パフォーマンスを重視するOSでは、モノリシックを採用している:
http://e-words.jp/w/E3839EE383BCE382AFE3839EE382A4E382AFE383ADE382ABE383BCE3838DE383AB.html

LC · NG

Minixを書いた教授(Tanen.)が、Linusへ送った批判の言葉:

「私は、特定のハードウェアに密接に関係した、特にIntel系のような
奇妙なCPUに依存したオペレーティングシステムを新たに書くことは、
基本的に間違っていると指摘しているだけです。OSそのものは、新しい
ハードウェアのプラットフォームに簡単に移植できるものでなければな
りません。25年前にIBM 360用にアセンブラでOS/360を書いても、おそ
らく大目に見てもらえたでしょう。しかし、10年前、8088用にMS-DOSを
書いた愚考を、IBMやMicrosoftは今になって認識しています。
1991年に386用のためだけの新しいOSを書くということは、今学期の成績
でもう1つ「不可」をもらうことにつながります。もちろん、期末試験で
うまくやれば、まだ単位を取得できるかもしれませんが。」

逆にLinusが教授なら、Tanen.には、不可を与えたことでしょう（苦笑）。

個人的には以前から、Linusの言葉の方が、心に届く言葉であるように
思えていたのですが、最近、Minixの実情を知ってからは、ますます、
感情的に、Linusを応援したくなってきています。

どうみてもLinusの方が色んな意味で歴史に残る人物なのに、この人
は、全く、、、。

LC · NG

>「特にIntel系のような奇妙なCPUに依存したオペレーティングシス
>テムを新たに書くことは、基本的に間違っていると指摘しているだけ
>です。」

心の奥底から、煮えくりかえりそうな嫌な感じを受けました。

"庶民の世界のパソコン"は、互換性を保ちつつ、徐々にスライドさせ
ていきながら、進化していく原則があるので、事実上、Intel以外の
プラットフォームが庶民に行き渡ることは当面ないんですよね。

工学の目的は、「物作りの手法を分析し、実際に役立てる」こと
だと私は思っているので、税金などから高いマシンを買って貰って、
悦に浸ってる工学研究者が許せません。

宇宙の研究とか、科学の基礎理論の研究をしている人なら、大いに
高いマシンを前提にすることも結構だと思うのですが、コンピュータ
のOSに関する工学的研究は、実際に今手に入る材料や環境で如何に
上手くやりくるするか、も当然重要になってくるはずで、訳の分か
らない独自SPECのマシンで遊んで偉そうにイバズリかえっている
この人のような人間は全く好きになれません。

こういう人種は人類にとってマイナスなんじゃないですかね。

**Be名無しさん** · NG

>> 16

でも、Linuxに関して言えば、カーネルには専用のメモリ空間が
ありますよね？つまり、2.はある意味正論になる？

**Be名無しさん** · NG

> 物理学などは、大学での研究が信頼性はかなり高いと思う。なぜなら、
> 全部理詰め、論理、数式などで精密に導いているから、実験を全く
> しなくても、ほとんどの場合、正しい結果を得られる場合が多いと
> 考えられるから。

ご冗談でしょう?

LC · NG

今目の前にあるマシンに、もっといいOSを載せたい、というのが、
自然な動機だと思います。

そして、それにはどうすればいいかを考え、解決策を提供するのが
本来の「工学」の姿ではないでしょうか。

「学問」は、実際に役立たなければ意味がありません。ただ、
基礎理論は、実際に役に立つんです。複雑な数式によって書かれている
ので一見理論の遊びのように見える人もいるかも知れませんが、
実際、かなり色んな事に応用が利くので、重宝しています。

しかし、工学は基本的にその場しのぎ的な教訓にどうしてもなってしまう
性質を持っているので、現実に即したことを前提にしないとほとんど
応用が利かないんです。物理学などでは、運動方程式を、惑星に対しても、
野球のボールに対しても適用できてしまうので、何にでも応用が利くので
すが、工学では、10年前の教科書の大部分が、実は今は役に立たないこ
とも実際にあります。なので、前もって研究するのではなく、なるべく
今の現実に沿わして常に調整しながら研究していかないと、誰も
役立てることが出来ないような、無駄な学問ばかりが出来てしまいます。

数百年前にできた古典物理学が今でも現役で利用できるのが、基礎理論
の凄いところですが、工学はなかなかそうはいきません。蒸気機関
の工学的な理論は、そのままでは今ではほとんど利用できないでしょう。
なぜなら、基礎理論を、具体的に「適用」した後の「結果」だからです。
なので、適用を実際に沿わせないと、今も十年後も全く利用価値のない
「ゴミ」の学問だけが遺ってしまいます。その点で、Linusの方が、
工学をよく理解していると思いますね。

LC · NG

Tanen.教授の主張は、どこを見ても狂ってるように思えます:
>しかし、10年前、8088用にMS-DOSを書いた愚考を、IBMやMicrosoftは
>今になって認識しています。

そもそも、そんなことを認識していると誰から聞いたんですかいな。

それに、当時、一番人気のあるのがIntel系でした。もともと、
8BITのIntel-8080Aが人気があり、Zilog社にZ80として移植され、
日本でもNECのTK80Aに8080A相当品、PC-8801シリーズには、Z80相当品
が用いられたことが有名です。それを16BITに拡張したのが、8086で、
それの安価版が8088です。しかし、当時、それを載せたパソコンは、
30万円～50万円したので、それ以上のCPUを望むことは出来ませんでした。
68000シリーズもあって設計はよいのは知られていましたが、
8080A,Z80,8086,8088系統とは全く互換性がないので余り人気がありま
せんでした。ですので、MSやIBMが、8086,8088を対象にしたのは、
正しい選択だったと思います。市場に受けいられるにはそれしかなかった
とも言えます。実際、68000シリーズは、マニア受けは良かったのですが、
余り大きな潮流にはならず、大して普及しなかったのです。

基本的に、市場=民意なので、市場が欲しがるものは、世の中で必要とされて
いるものなのです。互換性を維持し続けないと、過去の資産が全く使えなく
なり、もし互換性を無視していたなら、ソフトウェアの実際的な運用に基づ
く発展は阻害されていたと思います。そもそも、市場で売れなかったと
思いますし、そうなれば、Tanen.教授の今の立場も無かったと思います。

市場が発展したからこそ、コンピュータサイエンスが政府などからも
支援の対象になって来たのでしょう。もし、互換性を全く考えずに
来ていたなら、今日のような発展はなかったと思います。

Tanen.教授の考え方は、全く的はずれで、どこか研究者の我が儘を感じ
させます。

**Be名無しさん** · NG

LCって誰？OSの開発者？

LC · NG

>>21
そもそも、OS研究に限っては、大学でも、大して「アカデミック」では
無いと思う。全然大したことやってない。

それから、半導体の分野でも、企業の方が大学より5年は進んでいる
と聞いたことがある。

実際問題、Intelの技術より上回っている自信がある日本の大学
研究室はどのくらいあるだろう。

というよりも、ないんじゃなかろうか。

実装技術は、デジタル・ドカタにやらせておいて、高度な理論(笑)は、
学者である自分たちのみが考えられ得る、みたいに傲慢になっている
人までいるようで、馬鹿げています。

**Be名無しさん** · NG

>>24
そうだよ。ってゆーか、知らんかったんかい。（ｗ

**Be名無しさん** · NG

> 例えば、read()コールを発行すると、モノリシックなら、キャッシュに載って
> いれば、タスク切り替えなしで単にmemcpy()で済むでしょうが、
> マイクロカーネルならば、必ずFSのタスクに切り替わる必要があると
> 思います。

はいはい、それは70年代の真実な。
readの先がキャッシュ可能でローカルにあるものとは限らないのが現実だ。
マイクロカーネルかモノリシックかなんて議論、いまどきナンセンスなんだよ。
こんなスレで嬉々としているLCよ、教科書の範囲で水遊びしていることに気付け。

**Be名無しさん** · NG

>>14
タネンバウムが本当にやりたかったのはMinixみたいな糞じゃなくてAmoebaだったんだけどなー
UNIXの次は分散OSってことでPlan9やAmoebaが出てきた
PS3によってようやく分散OSが市民権を得るって時代になってんだけどなー

24 · NG

>>26
知らんかった。詳しく教えてちょ！

**Be名無しさん** · NG

>>29
ここに書いてあるのは全部コピペだよ
http://pc.2ch.net/test/read.cgi/os/1026581522/

本人はもう2chからは手を引いたと言われている
ちょうど今日、彼のスレが幕を閉じた...
http://pc.2ch.net/test/read.cgi/os/1057237050/

**Be名無しさん** · NG

分散OSをさらに発展させるのは次世代プロセッサCELLになり得るか。
ちなみに、CELLで動くOSはモノリシックカーネルになるのだろうか、
それともマイクロカーネルか？

**Be名無しさん** · NG

マイクロカーネルが性能面で劣ることはタネンバウム自身
認めているので、そこを突いても無駄。

拡張性・生産性・ネットワーク透過という面の比較キボンヌ。

29 · NG

>>30

あぁ、LCってLightConeの略か！「OSを作ろう」スレにも登場してた
人ですね。失敬。。。
でも、2chから手を引いたのなら何故このスレにいるのでしょうか？
お話は非常に面白いし参考になります、はい。

29 · NG

>>33
だから本人じゃなくてどっかの厨が過去ログからコピペしてるだけっつってんじゃん

30 · NG

失敬。
>>34の名前はミスです。
本当は30でした。

**Be名無しさん** · NG

拡張性は、理論的にはマイクロカーネルがの方が上のはずだが、
実際、モノリシックカーネル＋モジュールという形式の方が上
に見えるが、いかがでしょう？

33 · NG

>>34
あ、そういうことね（＾＾；

**Be名無しさん** · NG

コピペであれ何であれ、
LightConeが一番しっかりしたこと書いてるように感じるのは気のせい？

◆1haVRB54HY · NG

>>38
気のせい。(Linusさん信者だったのね。ふーん（´_ゝ｀）
つか、どっかでNWSOSをマイクロにしたいとか逝ってなかった？

**Be名無しさん** · NG

　∧||∧
（　 ⌒ ヽ　>>38
　∪　　ﾉ　お前が感じている感情は精神的疾患の一種だ。
　　∪∪　鎮める方法はない。逝ってよし。

**Be名無しさん** · NG

>>39

855 名前： LightCone ◆sSJBc30S5w 投稿日： 03/06/21 23:04
NWSOSの開発を続行するかどうかよく分からないのですけど、取りあえず
メモリ取得の速度のオーダーを順番に確保していくときはO(1)程度に
高速化して、さらに、セクタバッファの探索にハッシュを用いたり、
ライブラリでファイルバッファをかまして高速化したりしたので、
ファイルやデータを扱うようなアプリは、かなり高速になったのですが、
さらに遅延書き込みも仮サポートしてみたおり、いっそ、マイクロカーネルに
しようかと思ったのですが、その利点に、かなり疑問があり、悩んでます。

なにか、ご意見有りませんか。

◆1haVRB54HY · NG

>>41
なんか他所でも逝ってた様な気がする。(つか、何が"かなり高速"だよ。(w

**Be名無しさん** · NG

>>42
この頃のLﾀｿは互換ライブラリを締め出した頃よりずっと良くなってたんだけどなー
今はわけわかんない精神世界に逝っちゃったから技術者としてはおしまいだーね
あんたも文句ばっか言ってないで簡単なゲームでいいから作ってみなー

◆1haVRB54HY · NG

>>43
そんなことしたいので、とりあえず図書館でまた本借りてきますた。

**Be名無しさん** · NG

>>44
できない奴はできないよ。
センスが無いんだから諦めろ。

**Be名無しさん** · NG

Minix使ったことある人っている？

**Be名無しさん** · NG

オブジェクト指向との親和性でマイクロカーネル優位。
これを生かすためにはオブジェクト指向言語が不可欠。
それもObjective-Cみたいな原始的なものがベスト。

**Be名無しさん** · NG

>>47
Darwinマンセー、だね！

**Be名無しさん** · NG

>>47
しかしパフォーマンスが悪いわな。
プロセス間通信によるオーバーヘッドをどう回避するか。

48 · NG

>>49
だからDarwinではMachの純粋性を諦めて、
ファイルシステムやネットワーキング、ユーザー管理といったものも
カーネル空間の中で動作するようにしちゃったわけよ。

**Be名無しさん** · NG

>>50
あれってモノリシックだったんじゃ？

48 · NG

>>51
そのことについて「Machの純粋性を諦めて」と書いたわけです。
ただ設計はどうあれMachのAPIは全部使えるのがミソでしょう。
QuartzなんかはMachのメッセージング機構を使いまくりなので
非MachのOSに移植するのは難しそうです。

**Be名無しさん** · NG

>>44
とりあえずあんたみたいな厨房にはC#がぴったりだよ。
間違ってもJavaとかRubyとかＷｉｄｅＳｔｕｄｉｏには手を出さないこと。
あんたと同レベルの基地外がうようよいる所だから、
基地外同士で連携されたりした日には
他人にどれだけ迷惑になるか分かったもんじゃないからな。

**Be名無しさん** · NG

>>52
ということはDarwinではモノリシックに軍配が上がったということ
ですよね？

**Be名無しさん** · NG

>>53
なんか必死に誘導しようとしているな

**Be名無しさん** · NG

Darwinの場合、UNIXであることが足かせになったってことだろな。
でっかい固まりとしてラップすることはできても、UNIX自体はオブジェクト指向ではない。
しかし、UNIXである利点は無視出来るもんでもない。

**Be名無しさん** · NG

いまさら、マイクロカーネルかモノリシックカーネルかで優劣競っても意味ないんじゃない？
RISC vs. CISC 論争を思い出すよ。

**Be名無しさん** · NG

>>54
現状では、ね。

CMTって言って、今後プロセッサの集積化がどんどん進むと思われるが、
1チップで16プロセッサとかなってくると、
果たして今のDarwinの構造が最適かという問題が出てくるだろう。
そうなってくると、むしろ1台のマシンの中で分散OS化した方が効率が良い。
でもここまでの高度化がJobsの言ってた「今後15年」っていうDarwinの寿命の中で
起きるかどうかは知らんけど。

**Be名無しさん** · NG

>>57
CPUが高速になった現代では意味のない議論だってことか？

**Be名無しさん** · NG

てか、UNIXが元々モノリシックってことか。

**Be名無しさん** · NG

>>59
同じことはJavaとか.NETとかのバイトコード方式にも言えるね

**Be名無しさん** · NG

>>58
現在の最高性能だけを視野に入れるならマイクロカーネルが有利だろうね。
最高性能だけを視野に入れるならだが。

57 · NG

>>59
というより、どちらもお互いのイイトコ取りしてパフォーマンス上げてるから純粋性無くなってるってこと。
デバイスドライバのモジュール化とかさ。

**Be名無しさん** · NG

最高性能が欲しいならﾓﾉﾘｼｯｸのほうが絶対有利。
タスクスイッチしなくていいから。
(だからとてLC氏のDOSﾏﾝｾｰはなんか違うのだが)

もっと性能がほしいならＯＳなんか使わないのが正しい。

なおLinuxのデバドラモジュールはﾏｲｸﾛｶｰﾈﾙとは関係ない。

57 · NG

>>64
そうだね。デバイスドライバのモジュールはマイクロカーネルのとは関係ないですね。

タスクスイッチなぁ。確かにですわな。
つーことは、単一プロセス・マルチスレッドでカーネル書くか、ってことだな。

**Be名無しさん** · NG

>>64
>>62は最高性能のマシンだけって意味だと思うけど。

**Be名無しさん** · NG

>>58
確かにCMTでもＳＭＰでも、マルチプロセッサになってくると、
マルチカーネルみたいなのに走りたくなってくる。

ただ、うまく作らないとロックのコストが高くなりすぎちゃうんだよね
カーネルをタスクで実装すると、そのあたりの設計の苦労が軽減する
気がする。（まあ別の苦労があるんだろうけど）

>>64
タスクスイッチのコストってそんなに大きいんだろうか
と常々思う。CPUが高速化するにつれ、他のコスト（キャッシュミスとか）
の方が大きくなっていくだろうね、きっと。

>>66
性能に関しては、MPマシンだとマイクロカーネル有利、1CPUならモノシリック有利
ってことじゃないかな

**Be名無しさん** · NG

s/モノシリック/モノリシック/
なんでかしらないが、素でよく間違える('A`)

◆1haVRB54HY · NG

月刊ASCIIのセイで今の今までずーと"モノシリック"と思ってますた。。。

**Be名無しさん** · NG

>>67
SMPとかだと、どうしてもロックに恐ろしいくらいコストかかる。
そんでもってプロセス生成が異常に遅くなる。
そうなってくるとマルチスレッドのサポート具合がOS性能決めてくる結果になってしまう。

**Be名無しさん** · NG

CMT : Coarse grained MultiThreading
CMP : Chip-level MultiProcessing
で良かったでしょうか？

**Be名無しさん** · NG

>>71
CMT: Chip MultiThreading
が普通じゃないかな？

71 · NG

>>72
THX!

**Be名無しさん** · NG

>>67
同一プロセス内でのスレッド切替はそんなに時間かからんよ。
VM切替を伴うものが問題。
だからスピードだけが欲しいならカーネル含めて
「単プロセス複スレッド」が有利。

もちろんVMはメモリ保護という重要な役割があるので
VMは欲しいことも多い。
(RTLinuxやVxWorksはこの辺がヘボいので苦労するらしい)

実際にはスレッドとかより>>70の言うような
排他ロック(mutex)による性能低下のほうが大きい。
ｼｽﾃﾑｺｰﾙ毎にｶｰﾈﾙを丸ごとロック(giant lock)する
昔のﾓﾉﾘｼｯｸｶｰﾈﾙはMPでは（思ったほど）性能が出ないことがある。

**Be名無しさん** · NG

>>74氏はご存知かと思うけど、「だったらプリエンティブカーネルに
すりゃいいじゃん」、と勝手に補足しておこう。

作るの地獄だけど。

**Be名無しさん** · NG

プリエンプティブとリエントラントを混同してる痛い香具師がいるな

**Be名無しさん** · NG

未だにカーネル丸ごとロックなOSって多いよね。
割込ロックだけにするとドライバとかプロトコルスタックとかも
全部書き直し必要だからしかたないと言えば仕方ないかもしれないけど。

**Be名無しさん** · NG

それわおめーだっつーの>>76

じゃ「リエントラントカーネル」て何よ。

プリエンプティブカーネルはリエントラントであることは必要条件だが

**Be名無しさん** · NG

どうでもいい話かもしれないか超漢字はマイクロカーネル採用らしい

**LightCone** ◆sSJBZiod2E · NG

(^_^;

**Be名無しさん** · NG

未来指向派 vs リアリスト、みたいなもんだろ。未来指向派がマイクロカーネル。

**Be名無しさん** · NG

モノリシックカーネルで
プリエンティブマルチタスクで、なおかつ
リアルタイムOSなんて可能なんですかね？

**Be名無しさん** · NG

Lﾀﾝ、OS作り

や　　ら　　な　　い　　か　　？

**Be名無しさん** · NG

WinNTは実用的なマイクロカーネルだね！

WinXPでは崩れてるかもしれないけど

**Be名無しさん** · NG

GNU Hurd は Windows の夢を見るか？

**Be名無しさん** · NG

>>84
前から崩れてる。
NT3.51のころはきれいだったんだが…

**Be名無しさん** · NG

カトラー vs ストールマン

**Be名無しさん** · NG

BSD Conでこのスレの話題が出てきて藁他

**Be名無しさん** · NG

>>82
「リアルタイムOS」を定義汁。
話はそれから堕。

Lﾀｿが「DOSが層ですが」に120ﾙｸｽ

**Be名無しさん** · NG

>>82
可能だろ。

リアルタイム性に影響するのはタスクスイッチ方式と
システムコールの不可分性。

**Be名無しさん** · NG

すまん間違えた。
タスクのスケジューリング方式。

**Be名無しさん** · NG

その「タスク」にカーネルのお仕事が入るかどうかで
>>75のような地獄を見るかどうかが決まるわけで。

マイクロカーネルにすればこの辺はずいぶん楽になるわけで。

**Be名無しさん** · NG

>>74の「SMPだとmutexのコストが増加する」っての解説きぼんぬ。

複数のCPUが一つの資源を同時に取りに行って、なかなか取ることが
できないから、その間はスピンロックで待ってるから遅くなる、
ってこと？

**Be名無しさん** · NG

>>89

モノリシックカーネルで
プリエンティブマルチタスクで、なおかつ
ハードリアルタイムOSなんて可能なんですかね？

**Be名無しさん** · NG

>94 実現可能性を知りたいなら作ってみれば？

漏れがその条件を満たすならマイクロカーネルにするけど。
楽だし。

**Be名無しさん** · NG

しかしｶｷｺしてる椰子で「リアルタイムＯＳ」がどんなもんか
分かてるのはどのくらいいるんだ？

Lﾀｿが力いっぱいｶｿﾁｶﾞｲしてるくらいだから無理もないが
「リアルタイムＯＳは速い」わけでわないぞ。

早毛りゃ世の中のＯＳ全部リアルタイムＯＳになってるはずだ罠

**Be名無しさん** · NG

>>96 Lなんとかはどうでもいいよ。

とりあえず、このスレはこの厨房板の割にはレベル高いので、
μITRONくらいは知ってると思うから別にいいよな？

**Be名無しさん** · NG

デスクトップでリアルタイムOSってメリットあるの？

**Be名無しさん** · NG

どうなんでしょう。
人間相手に1msレベルの応答速度はいらないし。

**Be名無しさん** · NG

>>98
CD焼きながらのマルチタスクに強い
そんなのは過去の話だというのは甘い
DVD8倍速焼きなんかだと他のアプリを起動してなくてもとりこぼす

**Be名無しさん** · NG

>>100
あーなるほど。
確かにP4 3G HTでもエンコしながら8倍で焼くとボロボロだね。

**Be名無しさん** · NG

>>101
そんなことがしたいなら素直に2台買うかDual Xeon(HT)にしろや

**Be名無しさん** · NG

>>98
ある。
マウスクリックしてから反応が返るまでの時間を保証できる。

藻前らのつかてるＯＳだとその時の機嫌で反応が遅かったりするだろが。

やっぱレベル低いじゃ
「名前を知ってる」と「中身を知ってる」は違うづら

**Be名無しさん** · NG

>>103
アプリが応答する時間までは保証できないんでは？

**Be名無しさん** · NG

> マウスクリックしてから反応が返るまでの時間を保証できる。

全てのRTOSが時間保証できるわけぢゃねーよ。
一部を全部のようにいう嘘つきは、レベルの高低以前の害悪だな。

**Be名無しさん** · NG

>>105
保証できないようなのはRTOSとは言わんが何か。

Soft RTOSなら必ずしも保証できん、ならわからんでもないが
分かってんなら最初からそう書くはずだよな？
知ったかｸﾝは幼稚園でやめとけ。

**Be名無しさん** · NG

ﾘｱﾙﾀｲﾑ性はﾃﾞﾊﾞｲｽﾄﾞﾗｲﾊﾞでだけ保証されてればｲｲﾔ
と思てる椰子もいるんでないかな。
(ﾘｱﾙﾀｲﾑLinuxの大半はそんな実装だし)

**Be名無しさん** · NG

> Soft RTOSなら必ずしも保証できん、ならわからんでもないが

Soft RTOS は RTOSではないと?
白馬非馬を使う詭弁野郎は、レベルの高低以前の害悪だな。

**Be名無しさん** · NG

かなり頭の悪い香具師が厄一名いるな

**素人様のお通りだ** · NG

　マイクロカーネルが遅いというのは聞くけど、BeOSってマイクロカーネルではなかった？
(どっかにそう書いてあった)あれは速かったと思うんだけど。
　それともここの人たちが言う「速い」「遅い」って体感速度は別の話なの？
　教えて偉い人！

**偉くない人** · NG

限界速度の話。

GUIやアプリまで含めてしまうと
そいつらの作りが巧いかﾍﾀｸｿかで
いかようにも体感速度は変わってしまう。
NT/Win2000/XPもマイクロカーネルだが体感どうよ。
（比べるなら同じ機械でね☆）

NT4以降はGDIがカーネル内なので純粋なマイクロカーネルではないのだが(>>84-86)

**Be名無しさん** · NG

漏れは音楽製作をＰＣ上でやってるんだが、最低1msの精度を出したかったりする。
そういうのに対応したOS欲しいな。BeOSが有力だったんだがZetaがどうなることやら

**Be名無しさん** · NG

>>112 漏れが作ってやるよ

それはそうと、音楽用途だと、1msの安定した出力が必要？
10msじゃダメ？　とかそういう意味で。画面出力ならVSYNCで
十分なんだけど、音楽方面は、からきし分からん。

**Be名無しさん** · NG

和音のタイミングを合わせたいとか。

**Be名無しさん** · NG

114はスルーで

**Be名無しさん** · NG

たとえばMIDIのレートは31.25[kbps]。
ノートONとノートOFFを連続して送ると6バイト=48[bit]。
所要時間はざっくり言って1.5[ms]ってとこ。
とはいえn重和音を出すならn倍の時間がかかる。
単に再生機材と割り切るのなら、10msを正確に測って
UARTの送信バッファに叩き込む程度の安定性があれば、
実用上は十分ではないのかと思われ。実際、プロ用機材でも
1msできっちり反応できるデバイスは少ない。
まーこれ以上の性能競争も、アーチストの制作意欲を
掻き立てるためには大事ね。

ちなみに入力デバイスを作るなら、時に100us単位の分解能が必要。

**Be名無しさん** · NG

自分の無知を指摘されて「攻撃的」だといい、
「うんざり」だとか「頭の中をクリア」しろなどという暴言まで書き込んでおきながら、
２ちゃん以下の話だと判明したら何も言わずに逃げましたか？

**113** · NG

>>116 ふむふむ。10ms単位の安定した処理ができれば音楽再生に
関しては無問題といったわけだ。もっと大変なのかと思ったけど、
意外と大したことなさそうだ。

もっとも、その程度のことが出来ていないことが多いわけだが。

実際には、割り込みの発生からコンテキストスイッチまでの
遅延なんかも一定していなければならないかな？

**Be名無しさん** · NG

>>117
それはOS-wikiのネタだろゴルァ（ｗ

**Be名無しさん116** · NG

>>118 これはMIDIの場合ね。ノンリニアの場合はもうちょっとシビア。

**Be名無しさん** · NG

>> とはいえn重和音を出すならn倍の時間がかかる
ので、高級なMIDIコントローラは複数のMIDI OUTがある。

実際には人間は50msくらいずれないと音がずれていると
認識できんらしいから、DTMやるだけならそんなに時間精度いらんのだが
MIDIを汎用の機器制御回線として使っていると数ms精度は欲しいかもしれん。

10msくらいなら汎用OS(Linux,Win)でもなんとかなるべ。
1msだと作り方による。
1msで「毎回サンプリング」くらいになるとRTOSでないときつい。

**121** · NG

当然だけど
RTOSを使えば魔法のように時間精度が精密になる

なんてｳﾏｰな話しはあるわけないので甘い夢はﾓﾂﾅﾖ
精度を上げやすいような機能はいろいろ備わってはいるが

**Be名無しさん** · NG

>>119
K氏の定義は通説より狭い感じがして違和感があるが、一応筋は通っているな
名無しは逝って良し
もなか氏のカキコが自分の味方だと思っているしな

**Be名無しさん** · NG

マイクロカーネルの方がいい場合って例えばどんな時？
保守性を考えなければモノリシックの方が良くない？
まぁモノリシックだと、カーネルモードで動くコードが多くなるから
セキュリティに関しては不安はあるけどさ。

**Be名無しさん** · NG

名無しの支離滅裂さは凄いな。

昔、B-FreeのMLのログをさらったら、あんなのがいぱーいで
ノイズがひどくてうんざりだった。

**Be名無しさん** · NG

age

**Be名無しさん** · NG

■■■■■■■■■■■TBS捏造報道疑惑■■■■■■■■■■■
１１／２朝、TBSのサンデーモーニングで
石原都知事が『日韓併合を１００％正当化するつもりはない』といった発言を
語尾が聞き取りにくく放送し、テロップで
『日韓併合１００％正当化するつもりだ！』
と表記しました。

左がサンデーモーニング　右が直後の番組サンデージャポン
http://yucarimint.hp.infoseek.co.jp/ishihara/up055666.jpg

詳細を知りたい方はニュー速+
http://news5.2ch.net/newsplus/
【報道】TBS「サンデーモーニング」が、石原都知事の日韓併合発言を編集捏造？スレへ

**Be名無しさん** · NG

>>124
カーネルのデバッグとか。

**Be名無しさん** · NG

「性能の悪いリアルタイムOS」もあれば
「性能のいい非リアルタイムOS」もあるわけで。
その辺がわかってない厨って結構いるよね。

**Be名無しさん** · NG

ここ厨房板だから、まともな板へ行って話続けない？

丸本 · NG

厨房板に相応しいレベルの話ししかでていないわけだが

**Be名無しさん** · NG

で、まともな板って何？

**Be名無しさん** · NG

Wikiの必死な議論好きについて…

ttp://www.tron-net.gr.jp/~takada/B-Free.old/mail-archive/mail3/all/threads.html#01394
ttp://www.tron-net.gr.jp/~takada/B-Free.old/mail-archive/mail3/all/maillist.html#01394

このへんの「Re: 周辺核のこれからの開発体制 (Re: B-Free マガジン)」
に流れが似てるな。H Suzuki氏ともう一人ぐらいのOO房が必死になって
オブジェクト指向にすれば開発が進むと主張して作者ともめた。
この後議論大好きOO房とその友達達がコミュニティ内の多数派になり
数ヵ月後にほとんど全てをしてきた作者が嫌気が差してやめる非常事態に
なった。

OO房は善意から必死になってカキコするから阿呆くさい。痴呆老人並に駄目。
無能な人達の駄目さに耐性がある人は悪い先例として目を通すの良いかと。

**Be名無しさん** · NG

>>111
LonghornでGDIもカーネルの外側に戻るみたいだね。

**Be名無しさん** · NG

>>124
> マイクロカーネルの方がいい場合って例えばどんな時？

保守性を考えるとき。

**Be名無しさん** · NG

>>133
名無しはつかえねーことばっか書いてるな。
「～と思ってました」が多すぎ。
しかも内容がひどい。おまえ以外にそんな誤解しねーよ。
奴はあれで議論だと思っているらしい。マジ阿呆くさい。
K氏ともなか氏に教えてもらっているだけじゃん。

名無しのカキコと奴へのレスを削ると、それだけですっきりしそうだね。

**Be名無しさん** · NG

いまだに名無しは一人だと思てる椰子ﾊｹｰｿ

**Be名無しさん** · NG

必死ですね

**Be名無しさん** · NG

必死です

**Be名無しさん** · NG

>>139
藁田

**Be名無しさん** · NG

Kタンも追い詰められて必死だね。
自分の間違いを認められないってダメじゃん。
やっぱ、OS議論は遠くで眺めるに限る。

**Be名無しさん** · NG

ウソつきと正直者系も定番クイズがわんさかあるよね。

**142** · NG

誤爆しますた。スマソ

◆1haVRB54HY · NG

>>141
我が師を冒涜するとは万死に値する。謝罪しる！

**Be名無しさん** · NG

>>144
おっ！男だねぇ。

**Be名無しさん** · NG

>>141
いつものことだ。
もう少し勉強した方がいいと思うんだけどねえ。
俺OSに籠るなら必要ないのかもしれないが。

**141** · NG

>>144
お前らには見えないかもしれないけど今、泣いて謝罪してます。

かなり釣れると思ったのだがあんまり釣れなくて残念賞。

**141** · NG

>>144
お前らには見えないかもしれないけど今、泣いて謝罪してます。

かなり釣れると思ったのだがあんまり釣れなくて残念賞。

**141** · NG

>>146
そうだね。

**Be名無しさん** · NG

なんだ、K氏はちゃんと間違いを認めているじゃないか。
間違いを指摘できなかった奴（>>141）が偉そうにほざいているのか。
自分じゃ指摘できないもんな、遠くで見ているしかないよな（藁

そういう俺も指摘はできなかったが、
間違いが分かったらすぐに認めるK氏を認められないほど愚かじゃない。

本物 ◆1haVRB54HY · NG

>>144=偽物。
しかし、ほぼ同意。

**Be名無しさん** · NG

自分の都合のいい時だけ本物言われてもなあ・・・
俺からみたらどっちも同じだろ

**Be名無しさん** · NG

>>147-148
君も漢だね！

**Be名無しさん** · NG

結局、図書館でホコリかぶってるような本を読んで、
「これがマイクロカーネルか！！」って感銘を受けても
今流のマイクロカーネルは、それとはだいぶ違うって事？

**Be名無しさん** · NG

>>154
まあそうかな。
LC氏の見解が一番まともって結論？こういうのは現在実装してる人の
意見に耳を傾けるのが近道。たとえばFreeBSDやNetBSDのメンテナ
とかね。*BSDがマイクロカーネルなのかは知らんが。
評論家にとっては定義がぐちょぐちょだと自分の金づるがいっぱい
できるメリットがあるので、あまりまともに受けないほうがいいわな。
実装する人とは逆。

**Be名無しさん** · NG

マイクロカーネルって要は、カーネルモジュールをユーザプロセスとして
動作させて、ユーザーアプリケーションはマイクロカーネルに対しては
システムコールで、OSサーバーに対しては共有メモリ(つまりMMU)を使ったIPCで
それらと通信するってことなんじゃないのかな。これがMachの実装形態だと
思うんだけど、他の形もあるのかな。どうなんだろ。
Lさんが散々言ってるように、肝心なことは概要じゃなくて実装の細部こそが
問題だってことでしょ。LinusもMachがパフォーマンスを上げるために、
実装があまりに複雑に成り過ぎているって指摘してるけど、Mach的なモデルが
優れていると言うのなら、そういった複雑な実装を全て見ないとダメだってことで。

**Be名無しさん** · NG

MachやL4やITRONなんかと、FreeBSDやNetBSDやLinuxやNWSOSや
OSASKは種類が違う。陸上のトラック走と、マラソン／競歩くらいジャンルの
差がある。だから前者をいじった知識が後者の全体構成にそのまます
んなり適用できるわけではない。
この国はそんなこともわからないエンジニアだらけのOS後進国という
自覚を持つように。特にいい年したおっさんは。

**Be名無しさん** · NG

>>157
どうちがうの？具体的に説明してみて

**Be名無しさん** · NG

むかーしむかし、王子の発言にこんなのが。

>74 名前：王子投稿日：02/05/29 14:00
>> OSASKはモノリシックでもマイクロでもないとか言ってますが、
>> その辺を　☆王子☆　に語ってもらいましょうか。
>
>OSASKのことは存在を知っている程度でよくわかりません。
>OSASKとは切り離した形でモノリシックカーネル（以下、モノ）と
>マイクロカーネル（以下、マイクロ）について語らせてもらいます。
>これに関してはカーネル空間に含める含めないの議論が
>されてきましたが、これは本質的ではないと思います。
>要は水平アーキテクチャか垂直アーキテクチャかの違いだと思います。
>一般的な汎用OS（WinであれUNIXであれ）は、モノとマイクロの
>中間的な存在です。要はどちら側に寄っているか、ということです。
>
>垂直アーキテクチャ：
>
>【第４層：アプリケーション】
>【第３層：サブシステム】
>【第２層：カーネル】
>【第１層：ハードウェア】
>
>水平アーキテクチャ：
>
>【第３層：サブシステム】【第４層：アプリケーション】・・・・
>-----------------------------------------------------------------
>【第２層：カーネル】
>【第１層：ハードウェア】
>
>なんかうまく表現できたとは思いませんが、マイクロの場合はカーネルより
>上はすべて横並びなわけです。AS/400などは水平アーキテクチャと垂直アーキテクチャを
>意識した設計となっています。「Inside the AS/400」などをごらんください。

**Be名無しさん** · NG

>>156
しかし、名無しの意見にも一理あると思うんだよな。
正確に言うと仮想マシンとの区別をどこにつけるかってことだけど、
たとえば「参照の前に特定のテストコードを挟まなければいけない」とかの規約を
作ったアドレス参照がすべて問題ないことを示すバイナリコードを
カーネルモードで動かした場合、
これをモノリシックカーネルとするか仮想マシン上のユーザモードを利用した
マイクロカーネルと見るかに分かれてもいいんじゃないか？
で後者の立場に立ったとき、この程度のものを仮想マシンと見るかどうか考えると・・・
ってことにはならないかな。

まあ話がズレてきてはいるんだが。

**ITRON名無しさん** ◆4WD27e3i1o · NG

> マイクロカーネルって要は

Machをもってマイクロカーネルを推察するのもどうかと。
それはさておき、どんな構成だろうと、真っ当に動きゃなんでもOKと思うんだが。
マイクロカーネルとは? とか言い出すからこじれるのであって。

**Be名無しさん** · NG

>Machをもってマイクロカーネルを推察するのもどうかと
いや、だからMach的なモデル以外のものがあるなら教えてと書いてあるじゃん。

**ITRON名無しさん** ◆4WD27e3i1o · NG

Mach"的"ってなによ?

**Be名無しさん** · NG

>>163
もういいです。結構です。

**Be名無しさん** · NG

Machでｼｽﾃﾑｺｰﾙとshmemが混じってるのは性能への妥協だろ。
純粋なマイクロカーネルならモジュール間通信は全部メッセージ。
（実現がINTかshmemかIPCかはいろいろある）
性能は当然犠牲になる。性能だけほしいならモノリシックにしとけ。

Machてそんなに人気あるのか？

**Be名無しさん** · NG

>>165
MacOS X → Mach

**Be名無しさん** · NG

別にMach人気でMacOSXが売れてるわけでわない罠

**Be名無しさん** · NG

>>112
>>121
OS/2ならフツーに1msの精度が出ますが...

**Be名無しさん** · NG

>>121

>実際には人間は50msくらいずれないと音がずれていると
>認識できんらしいから、DTMやるだけならそんなに時間精度いらんのだが

１音同士のずれでは気づかないけど、パターン化された音の連なりだと
かなりシビアになるらしい。

**Be名無しさん** · NG

machよりl4を題材にした方がいいような気がする。

**Be名無しさん** · NG

>>170
L4ってのはVMMやドライバすらもユーザー空間で動かすんだっけ？

**Be名無しさん** · NG

リック・ラシッドですが、何か？

**Be名無しさん** · NG

>>162
Amoeba: タネンバウム
Mach: CMU
Chorus: INRIA
MOS: HUJ
V-system: Stanford
Topaz: DEC/SRC

こんなもんですか？

**Be名無しさん** · NG

タネンバウム萌え

**Be名無しさん** · NG

てかさー、マイクロカーネルって発展途上だからモノリシックカーネルと比べるのがまちがいなような・・・

マイクロカーネルの欠点ってプロセス間通信のオーバーヘッドが大きいのが理由らしいけどさ

ハードウェアMMUみたいに、CPUプロセッサーにハードウェアIPCうわおまえらなおががうがうがｙ

**Be名無しさん** · NG

てかさ、すでに存在しているカーネルを設計が古いだっけ？
そういって否定するのはおかしいと思う。
生まれてきた人間にクローンは駄目だって言うみたい。
差別だと思うんだけど。

**Be名無しさん** · NG

255 名前：名無し~3.EXE 投稿日：04/07/29 (木) 20:11 ID:ESu4RNUy
>>252
>初期のOS Xの絶望的な重さは一体何だったんだろう？
単に、最適化不足だと思われる。

>OS Xの方がNT系のWindowsに似ている気がした
歴史的にカーネルが似ているのは必然と言える。
昔はUNIXの様な一枚岩カーネルが主流で、同時処理もマルチタスクによる
ものが一般的だったが、リック・ラシッドという人がマイクロカーネル/
マルチスレッドというものを開発し、Mach(マーク)というカーネルを作った。
MachカーネルはMac OSXのご先祖様に当たるNeXT StepというOSで使われた。

一方、このマイクロカーネル/マルチスレッドに強く影響を受けて開発された
OSがWindows NT3.1になる。特にNT3.51までのNTはほぼ完璧なマイクロ
カーネルシステムで、Win32APIもマイクロカーネル上で動作する1つのサブ
システムに過ぎなかった。(他にPOSIXサブシステムなどもあった)

その後、純粋なマイクロカーネルではパフォーマンスが出ないことが問題に
なり、Win32サブシステムと画面周りがカーネルに一部統合された。これが
NT4.0。

Appleは Jobsの再来により、旧来のOSを捨て(単なるエミュレータに置き換え)
まったく別の構造を持つDarwinカーネル(MachのOpenな後継版)を持つ
Mac OSXに至ったわけだ。

故に、どちらもマルチプロセス処理よりもマルチスレッド処理に重点が置かれ
マルチスレッドを使用したアプリケーションでパフォーマンスが出るように
設計されている。 OSXとNT(Windows Xp)は異母兄弟のようなもの。
互いに模倣し合って、今がある。

ちなみにMachを開発したリック・ラシッドはMicrosoft Researchにいる。

**Be名無しさん** · 05/02/01 23:33:51

マイクロカーネルに関してどうしてもわからない事があるのですが、
どなたか教えて下さい。

マイクロカーネルではシステムサーバによってOSの機能が実現されますよね？
そのとき、どのシステムサーバが何のサービスをしているか、
という問題を解決しなければならないと思うのですが、
そのあたりどうしているのでしょうか？
RPC使っているシステムもあるようですが…。

**Be名無しさん** · 05/02/02 01:03:29

http://www.pichi-pichi.com/index3.html

**Be名無しさん** · 05/02/02 10:18:07

>>178
何がいいたのかよく分りません

**ITRON名無しさん** ◆4WD27e3i1o · 05/02/02 23:33:02

>>180
要するにサービスルックアップの仕組みはどうなっとんじゃゴルァって
話をしたいんじゃないのかしら? 違うかしら?

**178** · 05/02/03 15:31:19

>>181
その通りです。

**終了厨房** · 05/02/03 21:08:38

ネームサーバ

================= 糸冬 =================

**Be名無しさん** · 05/02/09 15:14:39

ｻﾝｸｽ>>177
そうなんだ、良く分かります多。Machがマイクロカーネルの初実装ですかね？
Mach開発者がm$に居る事までわかりましたが、Machは氏に体？

**ITRON厨房** · 05/02/17 16:35:47

>>183

よーするに、

　URI -> IPアドレス

と

　サービス名 -> ポート番号

は同じような事ってこったな。

**Be名無しさん** · 05/02/26 18:19:35

簡単に言うと Linux の方が物知り。

**Be名無しさん** · 05/03/19 16:57:06

＞僕は遅いプログラムが嫌いで、手元の速いマシンの上に、ノロノロ動いているプログラムがあって、
＞コンピュータ全体の性能が落ちているのには耐えられない。
http://www.linux.or.jp/JF/JFdocs/linus-lecture/design.html (>>17のリンク一つ前)
Linusたん(;´Д｀)ﾊｧﾊｧ
そりゃマイクロカーネルOut of 眼中なわけだわｗ

**Be名無しさん** · 2005/03/21(月) 09:54:52

カーネルにウィンドウシステムをぶち込む英断が欲しいね

**Be名無しさん** · 2005/04/02(土) 17:52:48

>>188
(ﾟ⊿ﾟ)ｲﾗﾈ

ところで窓鯖2003はIIS6の一部までカーネルモードで動かす荒技やってる・・・
http://www.atmarkit.co.jp/fwin2k/dnsvrguide/iisperf/iisperf_02.html

今広告キャンペーンでWindowsServer2003+IIS>Linux+Apacheなんてやってるけど
そんなの当然としか思えないｗ
セキュリティ・ホールのないIIS書ける自信はどこから来るのかと（ｒｙ

こんなことするぐらいなら
今となっては立場MS>>>Intel・AMDなんだから（IntelにはAMD64互換EM64Tにしたメリットないし）
「モード遷移軽いCPUに汁( ﾟДﾟ)ｺﾞﾙｧ!!」言ってくれた方がよっぽど(・∀・)ｲｲ!!

**Be名無しさん** · 2005/04/06(水) 13:40:11

近い未来に実用化されるといわれる量子コンピューターに搭載されるOSは、
マイクロカーネルだろうか、それとも、モノリシックカーネルだろうか。

その前に、量子コンピューターに僕らの言う「ＯＳ」が走るかどうかも、疑問だけどね(w

**Be名無しさん** · 2005/04/11(月) 20:54:41

( >>96＞「リアルタイムＯＳは速い」わけでわないぞ。 )
あらゆるところでアルゴリズムの選択基準が最大時間↓優先（だいたい平均時間↑）だもんねー

**終了厨房** · 2005/05/25(水) 18:15:37

UNIX板かLinux板あたりに移動しない？　ちゃんと相手するよ。
machスレでもいいし。

**Be名無しさん** · 2005/09/12(月) 15:57:20

http://pc.watch.impress.co.jp/docs/2005/0912/kaigai211.htm
＞ある業界関係者は「Windows NTの当初の思想だったマイクロカーネルに、再び立ち戻ったように見える」と語る。
＞実際、Microsoft自身もMicrokernelized hypervisor(マイクロカーネル化ハイパーバイザ)と呼んでいる。

**Be名無しさん** · 2006/01/13(金) 02:00:48

離脱

**Be名無しさん** · 2006/02/28(火) 01:49:32

マンセー

**Be名無しさん** · 2006/06/13(火) 14:50:49

age

**Be名無しさん** · 2006/06/21(水) 02:35:22

リアルタイムとは、要求される最小時間単位と同等もしくはそれ以上の時間分解能があることを意味する。
例えば、1時間に1回だけ動けばよいシステムでは、最小単位時間が1分でも十分なリアルタイム性があるということだ。

**Be名無しさん** · 2006/07/21(金) 19:48:28

>>184
俺 "Optimizing PowerPC Code" ってアセンブラの本持ってるんだけど、その著者は
だいぶ前からラシッドと同じ M$ Research にいて、もはや PowerPC とは関係ない研究を
している模様。
こうやって金で有能な人を幽閉して技術が外に出ないようにしているのかなと。

>>189
今更その手の常識的な話はﾂﾏﾝﾈ
Linux だって kHTTPd ってのがあるじゃん。
それに、NFS サーバとかも、今ってカーネルモードで動いてるんでしょ。

**Be名無しさん** · 2006/07/22(土) 14:58:28

今はカーネルモードどころか専用ハードウェアで動かす時代だしなあ

**Be名無しさん** · 2006/08/13(日) 08:08:40

>>190
つうか量子コンピュータで動くアルゴリズムを記述できる言語をまず何とかしてくれ。