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

このエントリーをはてなブックマークに追加
1 ：Be名無しさん：
一度本気で語ってみたい題目。リーナスvsタネンバウムで
いろいろネタは出てるが、時代は変わっている。もう一度
語ってみようじゃないか。

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

何でもいいので語ろう。
2 ：Be名無しさん：03/10/12 15:40
おいおいおい・・・2getかよ
3 ：2：03/10/12 15:40
初2getｷﾀ━━━(ﾟ∀ﾟ)━( ﾟ∀)━( ﾟ)━( )━(ﾟ )━(∀ﾟ )━(ﾟ∀ﾟ)━━━!!!!!
4 ：Be名無しさん：03/10/12 15:41
このスレはマジに語れるのか？？？？？？
5 ：Be名無しさん：03/10/12 15:42
>>3
晒し上げ
6 ：LC：03/10/12 15:47
マイクロカーネルが、モノリシックカーネルより、いくつかの点で
「よい」とか言う主張だって、いい加減さは同じだよ。

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

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

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

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

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

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

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

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

現場で実際にやってみると、間違ってたら動かないので気付くんだけど、
工学を馬鹿真面目にやってるだけでは気付かずに、馬鹿知識蔓延するよ、
まじで。
7 ：4：03/10/12 15:48
組み込み向けにはマイクロカーネルがいいと思われ
モノリシック＆モジュールは便利だが、モジュールがこけると
カーネルごとこけるのがいただけない
8 ：LC：03/10/12 15:48
前にも書いたと思うけど、Tanenbaum教授は、マイクロカーネルを
信奉している人。一方、Linusは、マイクロカーネルに大した価値を
見出さない人で、むしろ、モノリシックカーネルを信奉している人。

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

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

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

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

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

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

しかし、実体はそうではないと思うのだ。
9 ：Be名無しさん：03/10/12 15:50
> 実際問題、商用UNIXでも、マイクロカーネルに移行する機会があったの
> にもかかわらず、速度パフォーマンスの面などを考慮した結果だと
> 思われるが、結局、採用されなかった。
Solarisより遥かに頑丈なTru 64 UNIXを知らんのだな。
OSF-1から連綿と続く系統なんだが。
10 ：1：03/10/12 15:53
Machは複雑になりすぎてるという論調はあるみたいだが、OSの研究
としては高く評価されているのでは？
11 ：Be名無しさん：03/10/12 15:56
> Solarisより遥かに頑丈なTru 64 UNIXを知らんのだな。
> OSF-1から連綿と続く系統なんだが。
HP-UXへ統合という名目で葬られましたが何か？
セットだったAlphaもItaniumへ統合って名目で葬られたしね。
で、結局Mach出身でシェアトップなのはOS Xだね。

∴Darwin <<<<<<<<<<<<<<< HP-UX <<<<<<<<<<< Tru64 <<<<<<<<<<<<<<< Solaris
<<<<< *BSD <<<<<<<<<<< (超えられない壁） <<<<<<<<<<< 犬糞
12 ：Be名無しさん：03/10/12 15:58
確かに理論だけでは語れない部分が多々あるのは確か。
実際に日本でOSの開発をしている開発者はどう思うので
しょうかねぇ
13 ：LC：03/10/12 16:05
マイクロカーネルの例として、Minix, Mach, WindowsNTについて。

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

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

WindowsNTは、ネットでの資料によれば、比較的高速らしいが、真偽
のほどはよく分からない。速度測定や比較は、やり方を適切にして、
考察を正確に行わなければ正しいことは言えないので、余りネットや
雑誌の資料は当てにならない。実感として特に遅い事はないと思うが、
WindowsNT系は、Windows9x系よりも明らかに遅いことは事実。
よって、このケースでもマイクロカーネルの方がやはり遅い。
しかも、遅さも無視できる程度ではない。
14 ：LC：03/10/12 16:07
Minixで、MMUを使わずにマイクロカーネルを採用する意図が、私には全く
理解できない。

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

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


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


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

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

よって、MMUを使っていないところの、Minixが仮に遅くないとしても、
マイクロカーネルの速度に関しては、何の根拠にもならない。
15 ：LC：03/10/12 16:10
保護するために複雑になる例 : メモリ確保

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

保護有りの例:保護機能を持つOSのシステムレベルでのメモリ確保
メモリブロックのヘッダ情報を、保護ページに格納することで、
アプリケーションが破壊することができないようになっている。
しかし、構造上、メモリブロック本体とヘッダの二種類が存在する
ことになり、適切に組まないと、メモリ空間を全部使い切ることが
できなくなったり、物理メモリ容量が余っているのに、ブロックの個数
制限があって事実上メモリ不足のようになってしまうことになるかも
しれない。前述のmalloc()に比べるとアルゴリズムが難しい。
16 ：LC：03/10/12 16:12
一応念のため:「マイクロカーネル」とは、ファイルシステム、タスクロード、
GUIシステムなどのOSの基本機能を、「タスク(プロセス)」にほぼ等価な形態で
実装する方式のことを言います。

次の理解は間違いです:

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

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

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

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

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

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

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

Mach:マイクロカーネルへ移行していくと速度低下が見られたため、モノリシック
に戻さざるを得ない状況になったが、未だこの欠点は克服されておらず、
パフォーマンスを重視するOSでは、モノリシックを採用している:
http://e-words.jp/w/E3839EE383BCE382AFE3839EE382A4E382AFE383ADE382ABE383BCE3838DE383AB.html
18 ：LC：03/10/12 16:17
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の方が色んな意味で歴史に残る人物なのに、この人
は、全く、、、。
19 ：LC：03/10/12 16:18
>「特にIntel系のような 奇妙なCPUに依存したオペレーティングシス
>テムを新たに書くことは、 基本的に間違っていると指摘しているだけ
>です。」

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

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

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

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

こういう人種は人類にとってマイナスなんじゃないですかね。
20 ：Be名無しさん：03/10/12 16:21
>> 16

でも、Linuxに関して言えば、カーネルには専用のメモリ空間が
ありますよね？つまり、2.はある意味正論になる？
21 ：Be名無しさん：03/10/12 16:21
> 物理学などは、大学での研究が信頼性はかなり高いと思う。なぜなら、
> 全部理詰め、論理、数式などで精密に導いているから、実験を全く
> しなくても、ほとんどの場合、正しい結果を得られる場合が多いと
> 考えられるから。

ご冗談でしょう?
22 ：LC：03/10/12 16:22
今目の前にあるマシンに、もっといいOSを載せたい、というのが、
自然な動機だと思います。

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

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

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

数百年前にできた古典物理学が今でも現役で利用できるのが、基礎理論
の凄いところですが、工学はなかなかそうはいきません。蒸気機関
の工学的な理論は、そのままでは今ではほとんど利用できないでしょう。
なぜなら、基礎理論を、具体的に「適用」した後の「結果」だからです。
なので、適用を実際に沿わせないと、今も十年後も全く利用価値のない
「ゴミ」の学問だけが遺ってしまいます。その点で、Linusの方が、
工学をよく理解していると思いますね。
23 ：LC：03/10/12 16:24
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.教授の考え方は、全く的はずれで、どこか研究者の我が儘を感じ
させます。
24 ：Be名無しさん：03/10/12 16:26
LCって誰？OSの開発者？
25 ：LC：03/10/12 16:28
>>21
そもそも、OS研究に限っては、大学でも、大して「アカデミック」では
無いと思う。全然大したことやってない。

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

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

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

実装技術は、デジタル・ドカタにやらせておいて、高度な理論(笑)は、
学者である自分たちのみが考えられ得る、みたいに傲慢になっている
人までいるようで、馬鹿げています。
26 ：Be名無しさん：03/10/12 16:31
>>24
そうだよ。ってゆーか、知らんかったんかい。（ｗ
27 ：Be名無しさん：03/10/12 16:32
> 例えば、read()コールを発行すると、モノリシックなら、キャッシュに載って
> いれば、タスク切り替えなしで単にmemcpy()で済むでしょうが、
> マイクロカーネルならば、必ずFSのタスクに切り替わる必要があると
> 思います。

はいはい、それは70年代の真実な。
readの先がキャッシュ可能でローカルにあるものとは限らないのが現実だ。
マイクロカーネルかモノリシックかなんて議論、いまどきナンセンスなんだよ。
こんなスレで嬉々としているLCよ、教科書の範囲で水遊びしていることに気付け。
28 ：Be名無しさん：03/10/12 16:35
>>14
タネンバウムが本当にやりたかったのはMinixみたいな糞じゃなくてAmoebaだったんだけどなー
UNIXの次は分散OSってことでPlan9やAmoebaが出てきた
PS3によってようやく分散OSが市民権を得るって時代になってんだけどなー
29 ：24：03/10/12 16:42
>>26
知らんかった。詳しく教えてちょ！
30 ：Be名無しさん：03/10/12 16:45
>>29
ここに書いてあるのは全部コピペだよ
http://pc.2ch.net/test/read.cgi/os/1026581522/

本人はもう2chからは手を引いたと言われている
ちょうど今日、彼のスレが幕を閉じた...
http://pc.2ch.net/test/read.cgi/os/1057237050/
31 ：Be名無しさん：03/10/12 16:46
分散OSをさらに発展させるのは次世代プロセッサCELLになり得るか。
ちなみに、CELLで動くOSはモノリシックカーネルになるのだろうか、
それともマイクロカーネルか？
32 ：Be名無しさん：03/10/12 16:49
マイクロカーネルが性能面で劣ることはタネンバウム自身
認めているので、そこを突いても無駄。

拡張性・生産性・ネットワーク透過という面の比較キボンヌ。
33 ：29：03/10/12 16:49
>>30

あぁ、LCってLightConeの略か！「OSを作ろう」スレにも登場してた
人ですね。失敬。。。
でも、2chから手を引いたのなら何故このスレにいるのでしょうか？
お話は非常に面白いし参考になります、はい。
34 ：29：03/10/12 16:52
>>33
だから本人じゃなくてどっかの厨が過去ログからコピペしてるだけっつってんじゃん
35 ：30：03/10/12 16:53
失敬。
>>34の名前はミスです。
本当は30でした。
36 ：Be名無しさん：03/10/12 16:54
拡張性は、理論的にはマイクロカーネルがの方が上のはずだが、
実際、モノリシックカーネル＋モジュールという形式の方が上
に見えるが、いかがでしょう？
37 ：33：03/10/12 16:55
>>34
あ、そういうことね（＾＾；
38 ：Be名無しさん：03/10/12 17:24
コピペであれ何であれ、
LightConeが一番しっかりしたこと書いてるように感じるのは気のせい？
39 ： ◆1haVRB54HY ：03/10/12 17:29
>>38
気のせい。(Linusさん信者だったのね。ふーん（´_ゝ｀）
つか、どっかでNWSOSをマイクロにしたいとか逝ってなかった？
40 ：Be名無しさん：03/10/12 17:30
　∧||∧
（　 ⌒ ヽ　>>38
　∪　　ﾉ　お前が感じている感情は精神的疾患の一種だ。
　　∪∪　 鎮める方法はない。逝ってよし。
41 ：Be名無しさん：03/10/12 17:32
>>39

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

なにか、ご意見有りませんか。
42 ： ◆1haVRB54HY ：03/10/12 17:41
>>41
なんか他所でも逝ってた様な気がする。(つか、何が"かなり高速"だよ。(w
43 ：Be名無しさん：03/10/12 17:54
>>42
この頃のLﾀｿは互換ライブラリを締め出した頃よりずっと良くなってたんだけどなー
今はわけわかんない精神世界に逝っちゃったから技術者としてはおしまいだーね
あんたも文句ばっか言ってないで簡単なゲームでいいから作ってみなー
44 ： ◆1haVRB54HY ：03/10/12 18:03
>>43
そんなことしたいので、とりあえず図書館でまた本借りてきますた。
45 ：Be名無しさん：03/10/12 18:35
>>44
できない奴はできないよ。
センスが無いんだから諦めろ。
46 ：Be名無しさん：03/10/12 19:25
Minix使ったことある人っている？
47 ：Be名無しさん：03/10/12 19:34
オブジェクト指向との親和性でマイクロカーネル優位。
これを生かすためにはオブジェクト指向言語が不可欠。
それもObjective-Cみたいな原始的なものがベスト。
48 ：Be名無しさん：03/10/12 20:55
>>47
Darwinマンセー、だね！
49 ：Be名無しさん：03/10/12 21:45
>>47
しかしパフォーマンスが悪いわな。
プロセス間通信によるオーバーヘッドをどう回避するか。
50 ：48：03/10/12 22:17
>>49
だからDarwinではMachの純粋性を諦めて、
ファイルシステムやネットワーキング、ユーザー管理といったものも
カーネル空間の中で動作するようにしちゃったわけよ。
51 ：Be名無しさん：03/10/12 22:41
>>50
あれってモノリシックだったんじゃ？
52 ：48：03/10/12 22:47
>>51
そのことについて「Machの純粋性を諦めて」と書いたわけです。
ただ設計はどうあれMachのAPIは全部使えるのがミソでしょう。
QuartzなんかはMachのメッセージング機構を使いまくりなので
非MachのOSに移植するのは難しそうです。
53 ：Be名無しさん：03/10/12 22:58
>>44
とりあえずあんたみたいな厨房にはC#がぴったりだよ。
間違ってもJavaとかRubyとかＷｉｄｅＳｔｕｄｉｏには手を出さないこと。
あんたと同レベルの基地外がうようよいる所だから、
基地外同士で連携されたりした日には
他人にどれだけ迷惑になるか分かったもんじゃないからな。
54 ：Be名無しさん：03/10/12 23:15
>>52
ということはDarwinではモノリシックに軍配が上がったということ
ですよね？
55 ：Be名無しさん：03/10/12 23:16
>>53
なんか必死に誘導しようとしているな
56 ：Be名無しさん：03/10/13 00:06
Darwinの場合、UNIXであることが足かせになったってことだろな。
でっかい固まりとしてラップすることはできても、UNIX自体はオブジェクト指向ではない。
しかし、UNIXである利点は無視出来るもんでもない。
57 ：Be名無しさん：03/10/13 00:11
いまさら、マイクロカーネルかモノリシックカーネルかで優劣競っても意味ないんじゃない？
RISC vs. CISC 論争を思い出すよ。
58 ：Be名無しさん：03/10/13 00:12
>>54
現状では、ね。

CMTって言って、今後プロセッサの集積化がどんどん進むと思われるが、
1チップで16プロセッサとかなってくると、
果たして今のDarwinの構造が最適かという問題が出てくるだろう。
そうなってくると、むしろ1台のマシンの中で分散OS化した方が効率が良い。
でもここまでの高度化がJobsの言ってた「今後15年」っていうDarwinの寿命の中で
起きるかどうかは知らんけど。
59 ：Be名無しさん：03/10/13 00:13
>>57
CPUが高速になった現代では意味のない議論だってことか？
60 ：Be名無しさん：03/10/13 00:13
てか、UNIXが元々モノリシックってことか。
61 ：Be名無しさん：03/10/13 00:15
>>59
同じことはJavaとか.NETとかのバイトコード方式にも言えるね
62 ：Be名無しさん：03/10/13 00:18
>>58
現在の最高性能だけを視野に入れるならマイクロカーネルが有利だろうね。
最高性能だけを視野に入れるならだが。
63 ：57：03/10/13 00:19
>>59
というより、どちらもお互いのイイトコ取りしてパフォーマンス上げてるから純粋性無くなってるってこと。
デバイスドライバのモジュール化とかさ。
64 ：Be名無しさん：03/10/13 06:53
最高性能が欲しいならﾓﾉﾘｼｯｸのほうが絶対有利。
タスクスイッチしなくていいから。
(だからとてLC氏のDOSﾏﾝｾｰはなんか違うのだが)

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


なおLinuxのデバドラモジュールはﾏｲｸﾛｶｰﾈﾙとは関係ない。
65 ：57：03/10/13 07:56
>>64
そうだね。デバイスドライバのモジュールはマイクロカーネルのとは関係ないですね。

タスクスイッチなぁ。確かにですわな。
つーことは、単一プロセス・マルチスレッドでカーネル書くか、ってことだな。
66 ：Be名無しさん：03/10/13 10:31
>>64
>>62は最高性能のマシンだけって意味だと思うけど。
67 ：Be名無しさん：03/10/13 16:54
>>58
確かにCMTでもＳＭＰでも、マルチプロセッサになってくると、
マルチカーネルみたいなのに走りたくなってくる。

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

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


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


68 ：Be名無しさん：03/10/13 16:56
s/モノシリック/モノリシック/
なんでかしらないが、素でよく間違える('A`)
69 ： ◆1haVRB54HY ：03/10/13 17:03
月刊ASCIIのセイで今の今までずーと"モノシリック"と思ってますた。。。
70 ：Be名無しさん：03/10/13 17:52
>>67
SMPとかだと、どうしてもロックに恐ろしいくらいコストかかる。
そんでもってプロセス生成が異常に遅くなる。
そうなってくるとマルチスレッドのサポート具合がOS性能決めてくる結果になってしまう。
71 ：Be名無しさん：03/10/13 19:46
CMT : Coarse grained MultiThreading
CMP : Chip-level MultiProcessing
で良かったでしょうか？
72 ：Be名無しさん：03/10/13 20:11
>>71
CMT: Chip MultiThreading
が普通じゃないかな？
73 ：71：03/10/13 20:58
>>72
THX!
74 ：Be名無しさん：03/10/14 03:09
>>67
同一プロセス内でのスレッド切替はそんなに時間かからんよ。
VM切替を伴うものが問題。
だからスピードだけが欲しいならカーネル含めて
「単プロセス複スレッド」が有利。

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

実際にはスレッドとかより>>70の言うような
排他ロック(mutex)による性能低下のほうが大きい。
ｼｽﾃﾑｺｰﾙ毎にｶｰﾈﾙを丸ごとロック(giant lock)する
昔のﾓﾉﾘｼｯｸｶｰﾈﾙはMPでは（思ったほど）性能が出ないことがある。
75 ：Be名無しさん：03/10/15 15:05
>>74氏はご存知かと思うけど、「だったらプリエンティブカーネルに
すりゃいいじゃん」、と勝手に補足しておこう。

作るの地獄だけど。
76 ：Be名無しさん：03/10/15 15:24
プリエンプティブとリエントラントを混同してる痛い香具師がいるな
77 ：Be名無しさん：03/10/15 15:38
未だにカーネル丸ごとロックなOSって多いよね。
割込ロックだけにするとドライバとかプロトコルスタックとかも
全部書き直し必要だからしかたないと言えば仕方ないかもしれないけど。
78 ：Be名無しさん：03/10/17 04:02
それわおめーだっつーの>>76

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

プリエンプティブカーネルはリエントラントであることは必要条件だが
79 ：Be名無しさん：03/10/17 09:59
どうでもいい話かもしれないか超漢字はマイクロカーネル採用らしい
80 ：LightCone ◆sSJBZiod2E ：03/10/17 20:33
(^_^;
81 ：Be名無しさん：03/10/17 23:41
未来指向派 vs リアリスト、みたいなもんだろ。未来指向派がマイクロカーネル。
82 ：Be名無しさん：03/10/18 11:09
モノリシックカーネルで
プリエンティブマルチタスクで、なおかつ
リアルタイムOSなんて可能なんですかね？
83 ：Be名無しさん：03/10/18 11:26
Lﾀﾝ、OS作り

や　　ら　　な　　い　　か　　？
84 ：Be名無しさん：03/10/18 15:08
WinNTは実用的なマイクロカーネルだね！









WinXPでは崩れてるかもしれないけど
85 ：Be名無しさん：03/10/18 15:37
GNU Hurd は Windows の夢を見るか？
86 ：Be名無しさん：03/10/18 16:44
>>84
前から崩れてる。
NT3.51のころはきれいだったんだが…
87 ：Be名無しさん：03/10/18 19:15
カトラー vs ストールマン
88 ：Be名無しさん：03/10/18 22:38
BSD Conでこのスレの話題が出てきて藁他
89 ：Be名無しさん：03/10/20 23:22
>>82
「リアルタイムOS」を定義汁。
話はそれから堕。


Lﾀｿが「DOSが層ですが」に120ﾙｸｽ
90 ：Be名無しさん：03/10/21 03:49
>>82
可能だろ。

リアルタイム性に影響するのはタスクスイッチ方式と
システムコールの不可分性。
91 ：Be名無しさん：03/10/21 03:58
すまん間違えた。
タスクのスケジューリング方式。
92 ：Be名無しさん：03/10/21 06:20
その「タスク」にカーネルのお仕事が入るかどうかで
>>75のような地獄を見るかどうかが決まるわけで。


マイクロカーネルにすればこの辺はずいぶん楽になるわけで。
93 ：Be名無しさん：03/10/21 17:38
>>74の「SMPだとmutexのコストが増加する」っての解説きぼんぬ。

複数のCPUが一つの資源を同時に取りに行って、なかなか取ることが
できないから、その間はスピンロックで待ってるから遅くなる、
ってこと？
94 ：Be名無しさん：03/10/21 19:39
>>89

モノリシックカーネルで
プリエンティブマルチタスクで、なおかつ
ハードリアルタイムOSなんて可能なんですかね？
95 ：Be名無しさん：03/10/21 19:50
>94 実現可能性を知りたいなら作ってみれば？

漏れがその条件を満たすならマイクロカーネルにするけど。
楽だし。
96 ：Be名無しさん：03/10/22 00:15
しかしｶｷｺしてる椰子で「リアルタイムＯＳ」がどんなもんか
分かてるのはどのくらいいるんだ？

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

早毛りゃ世の中のＯＳ全部リアルタイムＯＳになってるはずだ罠
97 ：Be名無しさん：03/10/22 02:22
>>96 Lなんとかはどうでもいいよ。

とりあえず、このスレはこの厨房板の割にはレベル高いので、
μITRONくらいは知ってると思うから別にいいよな？
98 ：Be名無しさん：03/10/22 16:43
デスクトップでリアルタイムOSってメリットあるの？
99 ：Be名無しさん：03/10/22 17:13
どうなんでしょう。
人間相手に1msレベルの応答速度はいらないし。
100 ：Be名無しさん：03/10/22 17:13
>>98
CD焼きながらのマルチタスクに強い
そんなのは過去の話だというのは甘い
DVD8倍速焼きなんかだと他のアプリを起動してなくてもとりこぼす
101 ：Be名無しさん：03/10/22 17:15
>>100
あーなるほど。
確かにP4 3G HTでもエンコしながら8倍で焼くとボロボロだね。
102 ：Be名無しさん：03/10/22 17:20
>>101
そんなことがしたいなら素直に2台買うかDual Xeon(HT)にしろや
103 ：Be名無しさん：03/10/22 18:45
>>98
ある。
マウスクリックしてから反応が返るまでの時間を保証できる。

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

やっぱレベル低いじゃ
「名前を知ってる」と「中身を知ってる」は違うづら
104 ：Be名無しさん：03/10/22 21:23
>>103
アプリが応答する時間までは保証できないんでは？

105 ：Be名無しさん：03/10/23 00:12
> マウスクリックしてから反応が返るまでの時間を保証できる。

全てのRTOSが時間保証できるわけぢゃねーよ。
一部を全部のようにいう嘘つきは、レベルの高低以前の害悪だな。
106 ：Be名無しさん：03/10/23 21:22
>>105
保証できないようなのはRTOSとは言わんが何か。

Soft RTOSなら必ずしも保証できん、ならわからんでもないが
分かってんなら最初からそう書くはずだよな？
知ったかｸﾝは幼稚園でやめとけ。
107 ：Be名無しさん：03/10/23 22:48
ﾘｱﾙﾀｲﾑ性はﾃﾞﾊﾞｲｽﾄﾞﾗｲﾊﾞでだけ保証されてればｲｲﾔ
と思てる椰子もいるんでないかな。
(ﾘｱﾙﾀｲﾑLinuxの大半はそんな実装だし)
108 ：Be名無しさん：03/10/24 09:15
> Soft RTOSなら必ずしも保証できん、ならわからんでもないが

Soft RTOS は RTOSではないと?
白馬非馬を使う詭弁野郎は、レベルの高低以前の害悪だな。
109 ：Be名無しさん：03/10/24 21:41
かなり頭の悪い香具師が厄一名いるな
110 ：素人様のお通りだ：03/10/27 21:12
　マイクロカーネルが遅いというのは聞くけど、BeOSってマイクロカーネルではなかった？
(どっかにそう書いてあった)あれは速かったと思うんだけど。
　それともここの人たちが言う「速い」「遅い」って体感速度は別の話なの？
　教えて偉い人！
111 ：偉くない人：03/10/28 03:56
限界速度の話。

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


NT4以降はGDIがカーネル内なので純粋なマイクロカーネルではないのだが(>>84-86)
112 ：Be名無しさん：03/10/29 18:07
漏れは音楽製作をＰＣ上でやってるんだが、最低1msの精度を出したかったりする。
そういうのに対応したOS欲しいな。BeOSが有力だったんだがZetaがどうなることやら
113 ：Be名無しさん：03/10/29 20:28
>>112 漏れが作ってやるよ

それはそうと、音楽用途だと、1msの安定した出力が必要？
10msじゃダメ？　とかそういう意味で。画面出力ならVSYNCで
十分なんだけど、音楽方面は、からきし分からん。
114 ：Be名無しさん：03/10/29 20:52
和音のタイミングを合わせたいとか。
115 ：Be名無しさん：03/10/30 15:18
114はスルーで
116 ：Be名無しさん：03/10/31 08:52
たとえばMIDIのレートは31.25[kbps]。
ノートONとノートOFFを連続して送ると6バイト=48[bit]。
所要時間はざっくり言って1.5[ms]ってとこ。
とはいえn重和音を出すならn倍の時間がかかる。
単に再生機材と割り切るのなら、10msを正確に測って
UARTの送信バッファに叩き込む程度の安定性があれば、
実用上は十分ではないのかと思われ。実際、プロ用機材でも
1msできっちり反応できるデバイスは少ない。
まーこれ以上の性能競争も、アーチストの制作意欲を
掻き立てるためには大事ね。

ちなみに入力デバイスを作るなら、時に100us単位の分解能が必要。
117 ：Be名無しさん：03/10/31 15:37
自分の無知を指摘されて「攻撃的」だといい、
「うんざり」だとか「頭の中をクリア」しろなどという暴言まで書き込んでおきながら、
２ちゃん以下の話だと判明したら何も言わずに逃げましたか？
118 ：113：03/10/31 18:30
>>116 ふむふむ。10ms単位の安定した処理ができれば音楽再生に
関しては無問題といったわけだ。もっと大変なのかと思ったけど、
意外と大したことなさそうだ。

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

実際には、割り込みの発生からコンテキストスイッチまでの
遅延なんかも一定していなければならないかな？
119 ：Be名無しさん：03/11/02 00:46
>>117
それはOS-wikiのネタだろゴルァ（ｗ
120 ：Be名無しさん116：03/11/02 13:47
>>118 これはMIDIの場合ね。ノンリニアの場合はもうちょっとシビア。
121 ：Be名無しさん：03/11/02 22:43
>> とはいえn重和音を出すならn倍の時間がかかる
ので、高級なMIDIコントローラは複数のMIDI OUTがある。

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

10msくらいなら汎用OS(Linux,Win)でもなんとかなるべ。
1msだと作り方による。
1msで「毎回サンプリング」くらいになるとRTOSでないときつい。
122 ：121：03/11/02 22:52
当然だけど
RTOSを使えば魔法のように時間精度が精密になる

なんてｳﾏｰな話しはあるわけないので甘い夢はﾓﾂﾅﾖ
精度を上げやすいような機能はいろいろ備わってはいるが
123 ：Be名無しさん：03/11/03 14:31
>>119
K氏の定義は通説より狭い感じがして違和感があるが、一応筋は通っているな
名無しは逝って良し
もなか氏のカキコが自分の味方だと思っているしな
124 ：Be名無しさん：03/11/03 17:11
マイクロカーネルの方がいい場合って例えばどんな時？
保守性を考えなければモノリシックの方が良くない？
まぁモノリシックだと、カーネルモードで動くコードが多くなるから
セキュリティに関しては不安はあるけどさ。
125 ：Be名無しさん：03/11/03 17:30
名無しの支離滅裂さは凄いな。

昔、B-FreeのMLのログをさらったら、あんなのがいぱーいで
ノイズがひどくてうんざりだった。
126 ：Be名無しさん：03/11/03 17:54
age
127 ：Be名無しさん：03/11/03 18:04
■■■■■■■■■■■TBS捏造報道疑惑■■■■■■■■■■■
１１／２朝、TBSのサンデーモーニングで
石原都知事が『日韓併合を１００％正当化するつもりはない』といった発言を
語尾が聞き取りにくく放送し、テロップで
『日韓併合１００％正当化するつもりだ！』
と表記しました。

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

詳細を知りたい方はニュー速+
http://news5.2ch.net/newsplus/
【報道】TBS「サンデーモーニング」が、石原都知事の日韓併合発言を編集捏造？スレへ
128 ：Be名無しさん：03/11/03 23:11
>>124
カーネルのデバッグとか。
129 ：Be名無しさん：03/11/04 08:48
「性能の悪いリアルタイムOS」もあれば
「性能のいい非リアルタイムOS」もあるわけで。
その辺がわかってない厨って結構いるよね。
130 ：Be名無しさん：03/11/04 12:13
ここ厨房板だから、まともな板へ行って話続けない？
131 ：丸本：03/11/04 13:03
厨房板に相応しいレベルの話ししかでていないわけだが
132 ：Be名無しさん：03/11/04 13:25
で、まともな板って何？
133 ：Be名無しさん：03/11/04 20:02
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房は善意から必死になってカキコするから阿呆くさい。痴呆老人並に駄目。
無能な人達の駄目さに耐性がある人は悪い先例として目を通すの良いかと。
134 ：Be名無しさん：03/11/05 00:53
>>111
LonghornでGDIもカーネルの外側に戻るみたいだね。
135 ：Be名無しさん：03/11/05 14:30
>>124
> マイクロカーネルの方がいい場合って例えばどんな時？

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

名無しのカキコと奴へのレスを削ると、それだけですっきりしそうだね。
137 ：Be名無しさん：03/11/06 04:11
いまだに名無しは一人だと思てる椰子ﾊｹｰｿ
138 ：Be名無しさん：03/11/06 09:50
必死ですね
139 ：Be名無しさん：03/11/06 12:28
必死です
140 ：Be名無しさん：03/11/06 16:45
>>139
藁田
141 ：Be名無しさん：03/11/06 19:38
Kタンも追い詰められて必死だね。
自分の間違いを認められないってダメじゃん。
やっぱ、OS議論は遠くで眺めるに限る。
142 ：Be名無しさん：03/11/06 22:23
ウソつきと正直者系も定番クイズがわんさかあるよね。
143 ：142：03/11/06 22:25
誤爆しますた。スマソ
144 ： ◆1haVRB54HY ：03/11/07 00:21
>>141
我が師を冒涜するとは万死に値する。謝罪しる！
145 ：Be名無しさん：03/11/07 00:43
>>144
おっ！男だねぇ。
146 ：Be名無しさん：03/11/07 02:12
>>141
いつものことだ。
もう少し勉強した方がいいと思うんだけどねえ。
俺OSに籠るなら必要ないのかもしれないが。
147 ：141：03/11/07 02:15
>>144
お前らには見えないかもしれないけど今、泣いて謝罪してます。

かなり釣れると思ったのだがあんまり釣れなくて残念賞。
148 ：141：03/11/07 02:16
>>144
お前らには見えないかもしれないけど今、泣いて謝罪してます。

かなり釣れると思ったのだがあんまり釣れなくて残念賞。
149 ：141：03/11/07 02:18
>>146
そうだね。
150 ：Be名無しさん：03/11/07 04:04
なんだ、K氏はちゃんと間違いを認めているじゃないか。
間違いを指摘できなかった奴（>>141）が偉そうにほざいているのか。
自分じゃ指摘できないもんな、遠くで見ているしかないよな（藁

そういう俺も指摘はできなかったが、
間違いが分かったらすぐに認めるK氏を認められないほど愚かじゃない。
151 ：本物 ◆1haVRB54HY ：03/11/07 15:42
>>144=偽物。
しかし、ほぼ同意。
152 ：Be名無しさん：03/11/07 16:19
自分の都合のいい時だけ本物言われてもなあ・・・
俺からみたらどっちも同じだろ
153 ：Be名無しさん：03/11/07 22:35
>>147-148
君も漢だね！
154 ：Be名無しさん：03/11/08 01:53
結局、図書館でホコリかぶってるような本を読んで、
「これがマイクロカーネルか！！」って感銘を受けても
今流のマイクロカーネルは、それとはだいぶ違うって事？
155 ：Be名無しさん：03/11/08 10:37
>>154
まあそうかな。
LC氏の見解が一番まともって結論？こういうのは現在実装してる人の
意見に耳を傾けるのが近道。たとえばFreeBSDやNetBSDのメンテナ
とかね。*BSDがマイクロカーネルなのかは知らんが。
評論家にとっては定義がぐちょぐちょだと自分の金づるがいっぱい
できるメリットがあるので、あまりまともに受けないほうがいいわな。
実装する人とは逆。
156 ：Be名無しさん：03/11/08 20:05
マイクロカーネルって要は、カーネルモジュールをユーザプロセスとして
動作させて、ユーザーアプリケーションはマイクロカーネルに対しては
システムコールで、OSサーバーに対しては共有メモリ(つまりMMU)を使ったIPCで
それらと通信するってことなんじゃないのかな。これがMachの実装形態だと
思うんだけど、他の形もあるのかな。どうなんだろ。
Lさんが散々言ってるように、肝心なことは概要じゃなくて実装の細部こそが
問題だってことでしょ。LinusもMachがパフォーマンスを上げるために、
実装があまりに複雑に成り過ぎているって指摘してるけど、Mach的なモデルが
優れていると言うのなら、そういった複雑な実装を全て見ないとダメだってことで。
157 ：Be名無しさん：03/11/08 21:18
MachやL4やITRONなんかと、FreeBSDやNetBSDやLinuxやNWSOSや
OSASKは種類が違う。陸上のトラック走と、マラソン／競歩くらいジャンルの
差がある。だから前者をいじった知識が後者の全体構成にそのまます
んなり適用できるわけではない。
この国はそんなこともわからないエンジニアだらけのOS後進国という
自覚を持つように。特にいい年したおっさんは。
158 ：Be名無しさん：03/11/08 22:12
>>157
どうちがうの？具体的に説明してみて
159 ：Be名無しさん：03/11/09 03:48
むかーしむかし、王子の発言にこんなのが。

>74 名前：王子 投稿日：02/05/29 14:00
>> OSASKはモノリシックでもマイクロでもないとか言ってますが、
>> その辺を　☆王子☆　に語ってもらいましょうか。
>
>OSASKのことは存在を知っている程度でよくわかりません。
>OSASKとは切り離した形でモノリシックカーネル（以下、モノ）と
>マイクロカーネル（以下、マイクロ）について語らせてもらいます。
>これに関してはカーネル空間に含める含めないの議論が
>されてきましたが、これは本質的ではないと思います。
>要は水平アーキテクチャか垂直アーキテクチャかの違いだと思います。
>一般的な汎用OS（WinであれUNIXであれ）は、モノとマイクロの
>中間的な存在です。要はどちら側に寄っているか、ということです。
>
>垂直アーキテクチャ：
>
>【 第４層 ：アプリケーション 】
>【 第３層 ：サブシステム 】
>【 第２層 ：カーネル 】
>【 第１層 ：ハードウェア 】
>
>水平アーキテクチャ：
>
>【 第３層 ：サブシステム 】【 第４層 ：アプリケーション 】・・・・
>-----------------------------------------------------------------
>【 第２層 ：カーネル 】
>【 第１層 ：ハードウェア 】
>
>なんかうまく表現できたとは思いませんが、マイクロの場合はカーネルより
>上はすべて横並びなわけです。AS/400などは水平アーキテクチャと垂直アーキテクチャを
>意識した設計となっています。「Inside the AS/400」などをごらんください。
160 ：Be名無しさん：03/11/09 14:55
>>156
しかし、名無しの意見にも一理あると思うんだよな。
正確に言うと仮想マシンとの区別をどこにつけるかってことだけど、
たとえば「参照の前に特定のテストコードを挟まなければいけない」とかの規約を
作ったアドレス参照がすべて問題ないことを示すバイナリコードを
カーネルモードで動かした場合、
これをモノリシックカーネルとするか仮想マシン上のユーザモードを利用した
マイクロカーネルと見るかに分かれてもいいんじゃないか？
で後者の立場に立ったとき、この程度のものを仮想マシンと見るかどうか考えると・・・
ってことにはならないかな。

まあ話がズレてきてはいるんだが。
161 ：ITRON名無しさん ◆4WD27e3i1o ：03/11/10 10:05
> マイクロカーネルって要は

Machをもってマイクロカーネルを推察するのもどうかと。
それはさておき、どんな構成だろうと、真っ当に動きゃなんでもOKと思うんだが。
マイクロカーネルとは? とか言い出すからこじれるのであって。
162 ：Be名無しさん：03/11/10 11:32
>Machをもってマイクロカーネルを推察するのもどうかと
いや、だからMach的なモデル以外のものがあるなら教えてと書いてあるじゃん。
163 ：ITRON名無しさん ◆4WD27e3i1o ：03/11/10 12:27
Mach"的"ってなによ?
164 ：Be名無しさん：03/11/10 13:23
>>163
もういいです。結構です。
165 ：Be名無しさん：03/11/10 16:37
Machでｼｽﾃﾑｺｰﾙとshmemが混じってるのは性能への妥協だろ。
純粋なマイクロカーネルならモジュール間通信は全部メッセージ。
（実現がINTかshmemかIPCかはいろいろある）
性能は当然犠牲になる。性能だけほしいならモノリシックにしとけ。

Machてそんなに人気あるのか？
166 ：Be名無しさん：03/11/10 22:23
>>165
MacOS X → Mach
167 ：Be名無しさん：03/11/11 22:28
別にMach人気でMacOSXが売れてるわけでわない罠
168 ：Be名無しさん：03/11/17 05:45
>>112
>>121
OS/2ならフツーに1msの精度が出ますが...
169 ：Be名無しさん：03/11/17 07:28
>>121

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

１音同士のずれでは気づかないけど、パターン化された音の連なりだと
かなりシビアになるらしい。
170 ：Be名無しさん：03/11/22 12:09
machよりl4を題材にした方がいいような気がする。
171 ：Be名無しさん：03/11/22 15:49
>>170
L4ってのはVMMやドライバすらもユーザー空間で動かすんだっけ？
172 ：Be名無しさん：03/11/30 20:53
リック・ラシッドですが、何か？
173 ：Be名無しさん：03/12/08 19:50
>>162
Amoeba: タネンバウム
Mach: CMU
Chorus: INRIA
MOS: HUJ
V-system: Stanford
Topaz: DEC/SRC

こんなもんですか？
174 ：Be名無しさん：04/02/19 23:17
タネンバウム萌え
175 ：Be名無しさん：04/03/27 07:40
てかさー、マイクロカーネルって発展途上だからモノリシックカーネルと比べるのがまちがいなような・・・

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

ハードウェアMMUみたいに、CPUプロセッサーにハードウェアIPCうわおまえらなおががうがうがｙ
176 ：Be名無しさん：04/05/02 14:34
てかさ、すでに存在しているカーネルを設計が古いだっけ？
そういって否定するのはおかしいと思う。
生まれてきた人間にクローンは駄目だって言うみたい。
差別だと思うんだけど。
177 ：Be名無しさん：04/07/29 21:53
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にいる。
178 ：Be名無しさん：05/02/01 23:33:51
マイクロカーネルに関してどうしてもわからない事があるのですが、
どなたか教えて下さい。

マイクロカーネルではシステムサーバによってOSの機能が実現されますよね？
そのとき、どのシステムサーバが何のサービスをしているか、
という問題を解決しなければならないと思うのですが、
そのあたりどうしているのでしょうか？
RPC使っているシステムもあるようですが…。
179 ：Be名無しさん：05/02/02 01:03:29
http://www.pichi-pichi.com/index3.html
180 ：Be名無しさん：05/02/02 10:18:07
>>178
何がいいたのかよく分りません
181 ：ITRON名無しさん ◆4WD27e3i1o ：05/02/02 23:33:02
>>180
要するにサービスルックアップの仕組みはどうなっとんじゃゴルァって
話をしたいんじゃないのかしら? 違うかしら?
182 ：178：05/02/03 15:31:19
>>181
その通りです。
183 ：終了厨房：05/02/03 21:08:38
ネームサーバ

================= 糸冬 =================
184 ：Be名無しさん：05/02/09 15:14:39
ｻﾝｸｽ>>177
そうなんだ、良く分かります多。Machがマイクロカーネルの初実装ですかね？
Mach開発者がm$に居る事までわかりましたが、Machは氏に体？
185 ：ITRON厨房：05/02/17 16:35:47
>>183

よーするに、

　URI -> IPアドレス

と

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

は同じような事ってこったな。
186 ：Be名無しさん：05/02/26 18:19:35
簡単に言うと Linux の方が物知り。
187 ：Be名無しさん：05/03/19 16:57:06
＞僕は遅いプログラムが嫌いで、手元の速いマシンの上に、ノロノロ動いているプログラムがあって、
＞コンピュータ全体の性能が落ちているのには耐えられない。
http://www.linux.or.jp/JF/JFdocs/linus-lecture/design.html (>>17のリンク一つ前)
Linusたん(;´Д｀)ﾊｧﾊｧ
そりゃマイクロカーネルOut of 眼中なわけだわｗ
188 ：Be名無しさん：2005/03/21(月) 09:54:52
カーネルにウィンドウシステムをぶち込む英断が欲しいね
189 ：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に汁( ﾟДﾟ)ｺﾞﾙｧ!!」言ってくれた方がよっぽど(・∀・)ｲｲ!!
190 ：Be名無しさん：2005/04/06(水) 13:40:11
近い未来に実用化されるといわれる量子コンピューターに搭載されるOSは、
マイクロカーネルだろうか、それとも、モノリシックカーネルだろうか。

その前に、量子コンピューターに僕らの言う「ＯＳ」が走るかどうかも、疑問だけどね(w
191 ：Be名無しさん：2005/04/11(月) 20:54:41
( >>96＞「リアルタイムＯＳは速い」わけでわないぞ。 )
あらゆるところでアルゴリズムの選択基準が最大時間↓優先（だいたい平均時間↑）だもんねー
192 ：終了厨房：2005/05/25(水) 18:15:37
UNIX板かLinux板あたりに移動しない？　ちゃんと相手するよ。
machスレでもいいし。
193 ：Be名無しさん：2005/09/12(月) 15:57:20
http://pc.watch.impress.co.jp/docs/2005/0912/kaigai211.htm
＞ある業界関係者は「Windows NTの当初の思想だったマイクロカーネルに、再び立ち戻ったように見える」と語る。
＞実際、Microsoft自身もMicrokernelized hypervisor(マイクロカーネル化ハイパーバイザ)と呼んでいる。
194 ：Be名無しさん：2006/01/13(金) 02:00:48
離脱
195 ：Be名無しさん：2006/02/28(火) 01:49:32
マンセー
196 ：Be名無しさん：2006/06/13(火) 14:50:49
age
197 ：Be名無しさん：2006/06/21(水) 02:35:22
リアルタイムとは、要求される最小時間単位と同等もしくはそれ以上の時間分解能があることを意味する。
例えば、1時間に1回だけ動けばよいシステムでは、最小単位時間が1分でも十分なリアルタイム性があるということだ。
198 ：Be名無しさん：2006/07/21(金) 19:48:28
>>184
俺 "Optimizing PowerPC Code" ってアセンブラの本持ってるんだけど、その著者は
だいぶ前からラシッドと同じ M$ Research にいて、もはや PowerPC とは関係ない研究を
している模様。
こうやって金で有能な人を幽閉して技術が外に出ないようにしているのかなと。

>>189
今更その手の常識的な話はﾂﾏﾝﾈ
Linux だって kHTTPd ってのがあるじゃん。
それに、NFS サーバとかも、今ってカーネルモードで動いてるんでしょ。
199 ：Be名無しさん：2006/07/22(土) 14:58:28
今はカーネルモードどころか専用ハードウェアで動かす時代だしなあ
200 ：Be名無しさん：2006/08/13(日) 08:08:40
>>190
つうか量子コンピュータで動くアルゴリズムを記述できる言語をまず何とかしてくれ。
201 ：Be名無しさん：2006/08/15(火) 01:55:50
>>200
サンスクリット
202 ：Be名無しさん：2006/12/26(火) 18:13:05

203 ：Be名無しさん：2007/01/19(金) 15:22:05 BE:504446494-2BP(300)
>>200 あたまいいじゃんｗ
204 ：Be名無しさん：2007/02/16(金) 22:09:46
Linuxでいうmoduleはマイクロカーネルじゃないんだよね?
Windowsでのdriverはマイクロカーネルに沿ったモデルになってるのかな?
VGA関係のコードとか非常に遅くなるそうなんだけど、よくwkrnなぁ。
205 ：Be名無しさん：2007/04/06(金) 04:58:02
#!/usr/local/bin/hosh
206 ：Be名無しさん：2007/04/10(火) 05:41:27
>>204
NTが純粋にマイクロカーネルだったのは3.51までだったと思った。
207 ：Be名無しさん：2007/08/25(土) 11:52:46
難しいことは良くわからんが、今のところモノシリックのlinuxが最強って事か
208 ：Be名無しさん：2007/11/19(月) 18:37:30
>>206

Vistaで描画周り(　ﾟдﾟ)､ﾍﾟｯ したらしいが。
209 ：Be名無しさん：2008/08/14(木) 10:10:00
hoshu
210 ：Be名無しさん：2008/08/15(金) 04:48:33
>>207

×モノシリック
○モノリシック

モノリスのほーであって物知りとは関係ないので注意
211 ：Be名無しさん：2008/11/11(火) 17:18:33
カーネルの機能をユーザー空間に出す意味がいまだに分からないんだけど
ユーザー空間⇔カーネル空間のコンテキストスイッチのコストが重いから？
でもカーネルと同期処理が必要なときは結局システムコール呼び出すしかないし
そもそもシステムコールのうち非同期で済むものなんて僅かだし
212 ：Be名無しさん：2008/11/11(火) 17:38:23
>>211
ユーザー空間にするとOSが安定するから。
アプリが死んでも他のアプリに影響が無いのと同じように、
ユーザー空間においておくと、そこで問題があってもカーネルに影響を与えずに
すむようになる。

パフォーマンスの話なら、カーネル空間におくよりかはパフォーマンスが劣るというのは
常識なので、みんな分かってやっている。それ以上に安定性のほうを重視しているということ。
213 ：Be名無しさん：2008/11/11(火) 18:37:32
安定なんて嘘ばっかりじゃん。サブシステムが死んだらそれで終わり。
デバッグがしやすい？嘘ばっかり。プロセス間通信が絡むアプリはデバッグ大変。
214 ：Be名無しさん：2008/11/11(火) 22:00:33
>カーネルの機能をユーザー空間に出す意味がいまだに分からないんだけど

カーネルの本当に中核の部分以外を別空間に隔離することで抽象化が容易になり、

・安全性が高まる
・設計が容易になる

そしてその代償として

>ユーザー空間⇔カーネル空間のコンテキストスイッチのコストが重いから？

このデメリットを蒙る。

最近になってようやくマイクロカーネルな商用OSに成功例が出てきた
最大の要因は、コンピュータ自体のプロセッシングパワーの増大。
ぶっちゃけるなら、ようやくマイクロカーネルで冗長化しても
何とか使えるだけの速度が手に入った、というだけの話。

マイクロカーネルの伝道者は、もっと前からソフトウェア的なチューニングで
モノリシックカーネルと遜色ない速度を実現していたとか嘘垂れ流してるけど、
言ってしまえば21世紀になってプロセッサが速くなるまで実用性なんか度外視して
理念に殉じていたのがモノリシックカーネル。

こいつらの多くはアンチMSも兼任していたりするので、
20世紀中に最も成功したマイクロカーネルの商用OSってNTだよね、
とか言うと顔真っ赤にしてモゴモゴ言い出すよｗ
215 ：Be名無しさん：2008/11/11(火) 22:03:06
>安定なんて嘘ばっかりじゃん。サブシステムが死んだらそれで終わり。

そのサブシステムは再起動してやれば、システム全体道連れにはならないかもしれないし。
実際メインフレーム系はそんな感じになってるよね。
まあ死んだサブシス叩いてたプロセスは救いようがないけど。

>デバッグがしやすい？嘘ばっかり。プロセス間通信が絡むアプリはデバッグ大変。

GNUのHurdがここまでグダグダな理由ってこれだよね。
理念としては優れているけど、デバッグが困難で追い込み切れない間に
世間ではLinuxが伸してしまって、結局開発リソースの調達に失敗した。
216 ：Be名無しさん：2008/11/11(火) 22:05:38
>言ってしまえば21世紀になってプロセッサが速くなるまで実用性なんか度外視して
>理念に殉じていたのがモノリシックカーネル。

言ってしまえば21世紀になってプロセッサが速くなるまで実用性なんか度外視して
理念に殉じていたのはマイクロカーネルだって… orz ﾏｱ文脈ﾃﾞ理解ｼﾃﾓﾗｴﾙﾖﾈ...
217 ：Be名無しさん：2008/11/11(火) 22:30:05
メインフレームとかサーバーだとOSが死なないことに意義はあるだろうけど
せいぜい1-2本のアプリが走るだけのクライアントはアプリがコケたらそれまで
2000からXPになってエクセルが倍位死にやすくなってたまらんかったもんな
218 ：Be名無しさん：2008/11/12(水) 08:30:47
みんなカーネルとか崇高な会話してる中でエクセル（笑死）
219 ：Be名無しさん：2008/11/12(水) 12:06:37
> こいつらの多くはアンチMSも兼任していたりするので、
> 20世紀中に最も成功したマイクロカーネルの商用OSってNTだよね、
> とか言うと顔真っ赤にしてモゴモゴ言い出すよｗ

っすげー偏見
ただの常識じゃん
お前がつきあってるのがすげー偏った奴等ばかりなんだろうと
思わざるをえないw
220 ：Be名無しさん：2008/11/12(水) 17:51:18
開発がしやすいってのもあったはずだけど
>>213もあって結局はわかりやすいモノリシックのほうが
開発者集めやすいから大量投入できるのをLinuxが証明しちゃった
221 ：Be名無しさん：2008/11/13(木) 17:57:10
モノリシックは金にならん。
全てが一つになっているから
カーネルのライセンスに引きずられる。

技術的というより政治的な面で
最先端の技術を使うのが不可能な状態に陥っている。
222 ：Be名無しさん：2008/11/13(木) 18:01:15
>>220
> 開発者集めやすいから大量投入できるのをLinuxが証明しちゃった
証明していない。

Linuxは所詮マイナーOSでしかない。

百歩譲ってメジャーだとしても、
メジャーなOSでモノリシックで成功した例がある程度。
223 ：Be名無しさん：2008/11/13(木) 18:38:10
>>221
FUDお疲れです。

nVIDIA のドライバとかが有名ですが、プロプライエタリなドライバを提供することを
妨げるものはなにもありません。

まぁロードする時に一瞬メッセージが出るけどな。

ディストロに入れてもらえないのは差別だとか泣き言は言わないようにwwwwwwww
224 ：Be名無しさん：2008/11/14(金) 18:14:53
nVIDIA のドライバを見れば分かるようにモノリシックカーネルでは
不可能なことがあるので、外部からドライバを読み込む
マイクロカーネル構造を採用するしかないのです。

完璧なモノリシックカーネルが作れないという証明ですねｗ
225 ：Be名無しさん：2008/11/14(金) 19:57:08
モジュール化とマイクロカーネル構造を混同してるの？　馬鹿なの？
226 ：Be名無しさん：2008/11/15(土) 00:20:17
静かに！今>>224でちんこが喋ったぞ！
227 ：Be名無しさん：2008/12/23(火) 05:03:36
モノリシックカーネルでもモジュール化することで
プロプライエタリなドライバをバイナリのまま供給する道もできたけど、
ソースがユーザの手元に届かないバイナリの塊を送りつけられることに
これはこれで危機感を抱く開発者やユーザーも居るわけで…

バイナリで供給されてブラックボックス状態のドライバやファームウェアを
英語圏ではブロブ（blob：塊）と呼んだりするそうな。

228 ：Be名無しさん：2009/01/12(月) 16:50:54
でも不思議だな。
linuxなどでは、GUIサブシステムはユーザー空間のさらにユーザーのプロセスで動くのに対し、
windowsでは少なくともユーザープロセスじゃないよね?新しいのは知らないけど、カーネルスペースで動いていたはず。
この辺の混沌を考えると、一概にカーネルの種類って語れないんだな／。

もっと完全性の高い原理主義的なもので比較してみたいなー。
229 ：Be名無しさん：2009/01/13(火) 13:24:16
>>228
昔と違うからねー状況が。比較自体無意味っつーか。
対立自体ナンセンスっつーか。
230 ：Be名無しさん：2009/01/13(火) 13:58:59
マイクロよりモノシリックの方が安定する
WindowsとLinuxを見れば明らか
231 ：Be名無しさん：2009/01/13(火) 15:01:06
おお、物知りが現れたw
232 ：Be名無しさん：2009/01/13(火) 17:23:26
モノシリックだとマルチコアで効率悪い気がする。
233 ：Be名無しさん：2009/01/13(火) 18:32:57
別に1枚カーネルでも内部のスレッドはあるんだし…
具体的にはどの辺が?
234 ：Be名無しさん：2009/01/14(水) 03:01:26
いやだからおまいら、この考察自体時代遅れなんだってば・・・
235 ：Be名無しさん：2009/01/14(水) 06:24:30
>>197
つ [時報]
236 ：Be名無しさん：2009/01/14(水) 16:24:28
マイクロカーネルとか念仏唱えてればご飯食えた時代があったんだね・・・
237 ：Be名無しさん：2009/01/14(水) 21:17:16
>windowsでは少なくともユーザープロセスじゃないよね?新しいのは知らないけど、カーネルスペースで動いていたはず。

NT系でグラフィックサブシステムをシステム空間で動作させていたのは、
NT4.0、2000、XPだけだよ。

NT自体は本来的な意味でれっきとしたマイクロカーネルだし、
実際のところこれまでに商用OSとして最も成功したマイクロカーネルOSだろう。

こんなイビツなものはもはやマイクロカーネルの体をなしていない、
目先のパフォーマンスのためにマイクロカーネルの理念を曲げたものは
もはやマイクロカーネルを名乗るべきではない、みたいな事をほざく
原理主義者にクソミソに貶されたりもした訳だけど、
そいつらは不思議なことにパフォーマンスを確保するためにネットワークスタックや
ファイルシステムやサーバをカーネルモードで動作させるUNIX系の実装には
なぜか全く反応しない、というダブルスタンダードを決め込んでいたりしたから面白い。
238 ：Be名無しさん：2009/01/15(木) 13:31:23
>>237
そんな原理主義者、おまえの近所にたまたまいただけじゃねw
239 ：Be名無しさん：2009/01/15(木) 15:52:45
原理主義者はUNIXは屑だって言いつづけてたよ
240 ：Be名無しさん：2009/01/19(月) 20:37:32
無料でも普及しないOSってある意味失敗だよね。
241 ：Be名無しさん：2009/01/19(月) 20:49:19
達成目標の定義もなしに「失敗」とか決めつける奴って笑える
242 ：Be名無しさん：2009/01/19(月) 20:55:24
特定のOSを名指ししたわけでもないのに別に怒らなくても。
243 ：Be名無しさん：2009/01/20(火) 06:49:38
でもAtomとかの省電力CPUが出てきてWindowsがシリコンディスクで普通に動くようになると
BeOSとかネットサーフィン用のお手軽端末目的のOSは
ほんとにもー失敗に終わったと言わざるを得ない。
244 ：Be名無しさん：2009/01/20(火) 09:29:54
ドザ必死だなw
245 ：Be名無しさん：2009/01/20(火) 12:09:57
ただのドザ工作員じゃんw
246 ：Be名無しさん：2009/01/25(日) 08:48:15
CEのことですね、わかります
247 ：Be名無しさん：2009/06/28(日) 20:57:01
モノリシックの方が良い。

なんたって物識りックカーネルって位だから、頭よさそうだし。単結晶シリコンっぽい。
（モノじゃなくでシングルって突っ込みはナシね）
248 ：Be名無しさん：2009/08/04(火) 07:24:49
結局今はハイブリッド式？
カーネルプロセス内にモジュールの代わりにスレッドがあるかんじ。
249 ：Be名無しさん：2009/08/08(土) 10:31:46
先祖孵りしてるよね。カーネル設計者はブレてる
250 ：Be名無しさん：2009/08/08(土) 13:50:49
>>248
Dragonfly BSDはもっと評価されてもいいと思う。

あとQNXも
251 ：Be名無しさん：2009/08/08(土) 14:29:21
Dragonfly BSDを指して「（たぶん理想的なBSD on ）Machだ」と言った人がいるとかいないとか
252 ：Be名無しさん：2009/08/09(日) 20:50:04
設計思想より実装
253 ：Be名無しさん：2009/08/11(火) 20:23:58
復活MINIX3が最後の希望
254 ：Be名無しさん：2009/11/25(水) 09:11:57
CISCとRISCが融合して外部CISC内部RISCになったように
モノリシックカーネルとマイクロカーネルも融合して外部モノリシック内部マイクロなハイブリッドカーネル化したのかな？
カーネルは１プロセスだけどカーネル内スレッドがいっぱい走ってるみたいな
255 ：Be名無しさん：2009/11/28(土) 13:35:53
>>254
今はお互いいいところをうまく合わせているよ。
256 ：Be名無しさん：2009/12/16(水) 08:56:28
国産の俺マイクロカーネル
Prex　http://prex-j.sourceforge.jp/
MPL OS　http://www.bekkoame.ne.jp/ha/kuwaya/
257 ：Be名無しさん：2009/12/29(火) 01:28:49
沢山のPEを持った並列計算機や、マルチコア、メニ－コアのマシン、
ネットワークに分散した計算機などを透明に制御するOS、
アーキテクチャーの異なるマシンをネットで繋ぎ合わせたシステムなどは、
多分モノリシックカーネルではダメ（上手く扱えない）だろう。
258 ：Be名無しさん：2009/12/31(木) 08:01:56
>>257
Roadrunner　のOSはRHELとfedoraですが。
259 ：Be名無しさん：2010/01/02(土) 18:21:38
>>257
モノシリック、マイクロ関係なくね？
260 ：Be名無しさん：2010/01/12(火) 07:16:07
今は１つのカーネルがマルチコアを制御してるけど
小型のカーネルが個々のコア毎に実行されるような実装ってありえないかな？
４コア位ならいいけど１００コアとかになったらキャッシュ問題等で一括スケジューリングは難しいと思うし
むしろ１００個の小さいカーネルを走らせたほうがよかったりとか・・・
261 ：Be名無しさん：2010/01/21(木) 18:58:52
物知り
262 ：Be名無しさん：2010/01/21(木) 19:43:09
物利子
263 ：Be名無しさん：2010/01/22(金) 22:28:13
CPUがマルチコアになるとカーネルってどうなるっていくんですか？
264 ：Be名無しさん：2010/01/22(金) 22:28:59
↑　すいません。どうなっていくんですか？です。
265 ：Be名無しさん：2010/01/23(土) 07:58:33
モノリシックカーネルの場合、ジャイアントロック（あるスレッドがカーネルの
一部を実行中だと、他のスレッドは止められる）をなくして、並列性を高める
ことが求められる。
マイクロカーネルは、最初からそういう風に設計しやすい、というのが
うたい文句のひとつ。
266 ：Be名無しさん：2010/01/24(日) 01:38:28
マイクロカーネルはカーネルをジャイアントロックしても
カーネル機能自体が小さい（モノリシックOSでも排他制御が必要な要素）で
ファイルシステム等の大きな機能はアプリと同じレベルで並列動作するから問題が少ないけど
モノリシックだとカーネルを再入可能にして必要部分だけロックとかしないとロック時間が長くなるだっけ？

でもその辺りはモノリシックでも結構こなれてきていて
むしろCPUキャッシュとかを意識して複数コアにどうやってスケジューリングするかとかが重要になってるっぽいよね、最近は。

個人的にはそれ以前の所（CPU間の同期周りや割り込み処理等）がよくわからんけど、
今はマルチコアが当たり前だから「使える」OSを作るためのハードルがめちゃ高くなったよね。
267 ：Be名無しさん：2010/02/04(木) 03:28:39
昔と違って、今はお互いのいいところを双方が取り入れているから、
宗教的に争う意味もなくなってきているんだよねえ。
268 ：Be名無しさん：2010/02/07(日) 07:13:23
LinuxやFreeBSDってファイルシステム等の機能がカーネル内部スレッド化されてたっけ？
マイクロカーネルのマの字も無い気がするのだけど
WindowsとMacOSはマイクロカーネルベースのハイブリッドだよね確か
269 ：Be名無しさん：2010/02/07(日) 14:23:32
Macは完全なマイクロ
いつの時代も最先端
Windoseがマイクロだったのは最初だけで今はモノシリ
いつもMacをパクって失敗ばかり(W
270 ：Be名無しさん：2010/02/07(日) 17:47:29
わぁ、モノシリな人が来た（棒）
271 ：Be名無しさん：2010/02/07(日) 17:53:03
２重の意味でモノシリだねｗ
272 ：Be名無しさん：2010/02/20(土) 07:30:06
もの知りの集うスレですか？
273 ：Be名無しさん：2010/02/20(土) 09:18:19
違いますが何故か寄ってきます
274 ：Be名無しさん：2010/02/20(土) 23:00:36
Mach3とMINIX3…とちらが正統マイクロカーネルの王者だろう？
モノリシックUNIXの正統王者はNetBSDです、これはゆずれません。
275 ：Be名無しさん：2010/04/11(日) 07:26:21
俺もOSを開発したい。
まずは、8ビットマシン(OSというより、DOSになるが)から始めるか……。
276 ：Be名無しさん：2010/04/11(日) 22:07:52
MSXturboRって8bitだったかな？
まぁ好んで茨の道を選ぶとはｗ
http://www.youtube.com/watch?v=BmUdPkarkQA
http://www.nodus.ne.jp/~ghost/msx/wios-j.html
http://www.nodus.ne.jp/~ghost/msx/uzix-j.html
277 ：Be名無しさん：2010/04/12(月) 11:47:37
ターボRはR800だよ。こんな感じの石
http://ja.wikipedia.org/wiki/R800
278 ：Be名無しさん：2010/04/12(月) 13:00:00
contiki
http://translate.google.co.jp/translate?hl=ja&langpair=en|ja&u=http://www.markn.org/contiki/
279 ：Be名無しさん：2010/04/16(金) 06:29:44
ひゃっはー、俺が物知りだせー
280 ：Be名無しさん：2010/04/17(土) 08:36:40
７年間で３００レスか・・・定番ネタだったけど思いのほか白熱しなかったんだな・・・
281 ：Be名無しさん：2010/04/17(土) 11:56:51
安いもの使ってサービス提供するっていうのが最近の風潮だもんな
中身なんてどうでもいいっていうか
それで高品質なものが手に入るし
googleのデータセンタとか見ても
282 ：Be名無しさん：2010/04/20(火) 17:33:14
分散システムの個々のPCがプロセスでそれらを統括するPCがカーネルとは言えないだろうか
283 ：Be名無しさん：2010/05/03(月) 07:26:08
>>197
この手の馬鹿ソフト屋は精度と確度の違いを全く理解していないから
歯抜けの出力だしても平然としてるんだよな。
284 ：Be名無しさん：2010/05/05(水) 17:34:56
1時間に1回動けば精度はどうでもいいって話だと、
例えば59分59秒に動作してログを記録した後1時間00分01秒にもう一度動いて、
さらに次は119分59秒先…なんていうデタラメな動作でもokってことなのか

1時間おきに1回、誤差10ナノ秒以下で動作、みたいな場合の制御はどーすんだｗ
285 ：Be名無しさん：2010/05/15(土) 07:06:18
俺RTOS系の人は固定プライオリティの割り込み可能スケジューラーを作ればRTOSって勘違いしてるよね
286 ：Be名無しさん：2010/05/15(土) 08:25:19
TORON以外はRTOSじゃないのにな
287 ：Be名無しさん：2010/05/15(土) 11:54:24
釣りで誤字とかw
288 ：Be名無しさん：2010/06/11(金) 07:51:21
なんかこう、タネンバウムもマイクロカーネルも批判されがちだけど、amiga系（aros.morphosとか）を見る限り実装によりけりなんじゃないかと思うのだが。
289 ：Be名無しさん：2010/06/11(金) 09:58:58
AmigaOSってマイクロカーネル系なの？
ちなみにマイクロカーネル考にはこんなのも有ってなるほどなと思ってたりする
ttp://d.hatena.ne.jp/oraccha/20100601/1275366559
290 ：Be名無しさん：2010/06/11(金) 17:58:32
うん。ただ、マイクロカーネルのくせに、x86向けに作ってないところが残念で仕方ない（arosを除く）。
あと、超漢字も軽いことで有名だよね。だから、実装次第なんじゃないかなと思うわけで。
マイクロカーネルはCPUの性能が上がってようやく使えるものになったみたいな意見もあるけど（それが事実かどうかはともかく）、ハードに合ったソフトを使うのは、悪いことじゃないよね。と思うのは僕だけですか。
291 ：Be名無しさん：2010/06/11(金) 20:47:44
超漢字は軽いんじゃなくて何も機能がないだけ
292 ：Be名無しさん：2010/06/11(金) 20:50:11
今の定義だと

・マイクロカーネル → プロセス毎にアドレス空間が分離して保護される

だけど本質的に「基本機能＋大きなサービス」と捉えれば保護は不要なわけで
B-TRONやAmigaOSは保護にかかる大きなオーバーヘッドと無縁だったんじゃなかろうか？

メッセージやコンテクストスイッチによるオーバーヘッドばかり注目されてるけど
実はその陰で動く仮想アドレス関連もバカにならないとか・・・
293 ：Be名無しさん：2010/06/11(金) 20:56:04
訂正
×保護は不要
○保護は無関係
294 ：Be名無しさん：2010/06/12(土) 08:49:43
リーナスとタネンバウムのも「マイクロvsモノリシック」じゃなくて「linux vs minix」みたいだし（2006年のは、まだ読んでないけど）
リーナスもマイクロじゃなくてmachの批判をしてる感じだから
なんだかんだでまともな議論はされてないんじゃないかと思う処はある
295 ：Be名無しさん：2010/06/12(土) 09:25:27
超漢字（B-right/V）はソース公開されてないから、中身がメッセージパッシングで作られてるかどうか
正直わからん。
外殻はメモリ共有して直接データをやりとりしちゃってそうな気がするんだが。
296 ：Be名無しさん：2010/06/12(土) 09:57:47
共有メモリーもIPCの一つの手法だし
「保護」さえ無視すればメモリ上にメッセージを編集してポインタを渡すのが一番速い？
ITRONは最近までメモリー保護は無かったはずだからBTRONもそんな感じじゃないかな？
MINIX1だってMMU無しの8086で動作する「マイクロカーネル（ちとアレだが）」だしね
297 ：Be名無しさん：2010/06/12(土) 10:51:43
メールボックスはポインタ渡しだけど...そういうインタフェースもなしでやっちゃってないかなとw
298 ：Be名無しさん：2010/06/12(土) 13:01:30
有名にしたのはMachとMINIXだけど
AmigaOSとかOS/9とか結構昔から実用化されてたんだね＞マイクロカーネル
299 ：Be名無しさん：2010/06/12(土) 22:02:22
よく判らないんだが、GNU Hurdてのは、Mach+BSDのマイクロなんだろ。
ということは、ハイブリッドじゃないdarwinとほとんど同じなわけだ。
だったらGNUはdarwinをマイクロにして公開しちゃえば良いと思うんだが駄目なのか？
300 ：Be名無しさん：2010/06/12(土) 23:20:31
HurdがBSDというのは初耳なんだが。
ていうかGNUプロジェクトがGPLでないものは取り込まんだろ。
301 ：Be名無しさん：2010/06/12(土) 23:26:24
俺は大きな勘違いをしていたようだ。すまない。
302 ：Be名無しさん：2010/06/13(日) 15:12:15
一時期はフリーUNIXの大本命だったのにね＞Hurd
蛇足だけどUNIXとしてはNetBSD
マイクロカーネルとしてはMINIX3が好き
他にはInfernoとかELATEとかQNXとか…主流になれない俺…orz
303 ：Be名無しさん：2010/06/13(日) 21:08:11
NetBSDはよいものだ
304 ：Be名無しさん：2010/06/13(日) 23:31:17
morphosのカーネルのquarkはQNXを参考にするつもりだったがL4を真似することにした。
みたいな事がwikiにあると思うんですが、L4やQNXなど（mach以外）を採用したり
参考にしてるOSってなにかありますか。ご存知でしたら教えて戴けますか。
なんだか、マイクロカーネルの人気が低いのはmachが原因な気がして、ならないのです。
305 ：Be名無しさん：2010/06/14(月) 12:07:22
たとえば分散OSで検索して出てくるのはmach以外も多くない？
306 ：Be名無しさん：2010/06/14(月) 12:39:06
HaikuOS (カーネルはNewOS）
307 ：Be名無しさん：2010/06/15(火) 12:52:26
ちょっとスレチだけどInfernoみたいなVM型カーネルも面白いな。
マシンパワーが有り余っている今、主にセキュリティ面のアドバンテージから流行ったりして。
308 ：Be名無しさん：2010/06/16(水) 17:05:57
カラーザウルスのＯＳはＸＴＡＬだった
309 ：Be名無しさん：2010/06/18(金) 18:19:37
あ、BeOSってハイブリッドだったんだ。
310 ：Be名無しさん：2010/09/03(金) 12:38:21
BeOSには夢が詰まっていた
311 ：Be名無しさん：2011/07/05(火) 15:38:14.65
>>302
> 一時期はフリーUNIXの大本命だったのにね＞Hurd

一年前のレスにレスだが、そんな時代はない。
Mach/マイクロカーネルが充分な速度を得ることは不可能、
それがはっきりした頃に開発が始まった。
312 ：Be名無しさん：2011/07/05(火) 15:57:26.72
> Mach/マイクロカーネルが充分な速度を得ることは不可能、
> それがはっきりした

へぇー。

ということは BeOS も Mac OS X も充分な速度を得てないんですね。
勉強になりました（棒）
313 ：Be名無しさん：2011/07/06(水) 07:05:36.09
今はLinux使ってるけどHurdが出たらそっちへ行く…って人が結構居たがな
もうはるか昔の話しではあるが
314 ：Be名無しさん：2011/07/11(月) 14:59:01.39
>>312
Mac OS XのBSD部分はカーネル内にある。
Mach/BSDはマイクロカーネルじゃない。

使ったことあればバカでも知っているはず。
taskリストに出てこないので。

wikipediaより
> Mach 3.0は、Mac OS Xのカーネルにも用いられているが、
> 実装はマイクロカーネルではない。

結局Machカーネルの外にBSDサーバーを出すことが出来なかった。
これはOSF/1もNEXTSTEPもそう。
そもそもMachは3になるまでBSDを機能拡張する形の実装だった

Machの外部サーバとして実装され、今も維持されてるのはHurdだけ。
315 ：Be名無しさん：2011/07/11(月) 19:39:20.46
MAC OS-Xはそうだね
で、BeOSは？
あと組込み系ならQNXとかも有るんだけど
Machだけ持ち出してマイクロカーネルは遅くて使いものにならないと言われてもねぇ
316 ：Be名無しさん：2011/07/16(土) 19:37:55.92
BeOSはほぼ死亡状態だからなあ。
Hurdの方がまだちゃんと維持されてるんじゃない?
ユーザ環境はDebianに出来るし。
317 ：Be名無しさん：2011/07/16(土) 20:43:51.41
ああ「マイクロカーネルは遅くて使い物にならないからHurdは全く期待されていなかった」
みたいなレスからの流れで実用的な速度のマイクロカーネルとして上げただけだから＞BeOS
具体的には>>311からの流れ
Machベースで完全に外部サーバー形式にしてるのはHurdだけかね？
初期のBSD on MachもNext StepもMacOS XもOSF-1もパーソナリティ－を内包してたよね？
ある意味Machの遺伝子を受け継いでパーソナリティを入れたり出したりしているのがWindowsNT系ってのが皮肉かな
318 ：Be名無しさん：2011/07/17(日) 17:22:39.21
初期はBSD on Machじゃなくて、Mach on BSDとして実装された。
version 2まで。

NTカーネルはモジューラカーネルで、Mach 3とはちょっと仕組みが違うね。
COM/OLEの枠組みで提供されているところはMachのサービスサーバに似てるけど、
コアな部分はカーネル内に動的リンクされてる。
319 ：Be名無しさん：2011/07/18(月) 01:11:55.93
そういやHurdはL4ベースのもあるみたいだけどどんなだろ？
あとタンバネウム先生の総決算MINIX3.xも悪くないと思う
320 ：! 【34.7m】 【東電 75.6 %】 ：2011/10/25(火) 22:47:17.77
モノリス・・・ぷっ
321 ：Be名無しさん：2011/10/28(金) 16:59:10.96
MachもMINIXも3.0で初めて本当のマイクロカーネルになったんだな
それいぜんはマイクロカーネルじゃないし…いや、なんとなく
322 ：Be名無しさん：2011/10/30(日) 21:39:01.41
現役のメジャーどころでまともなマイクロカーネルってWindows(Vita以降？)だけ！？
MacOSはmachベースでもマイクロカーネル的には作られてないらしいし
MINIX3やDragonflyBSDはマイナーだし…
323 ：! 【14.2m】 【東電 84.8 %】 ：2011/11/03(木) 21:57:24.05
vms
324 ：Be名無しさん：2011/11/03(木) 22:01:21.27
現役？マイクロカーネル？？（今）メジャー？？？
325 ：Be名無しさん：2011/12/05(月) 10:14:33.72
いまや純粋なマイクロカーネルは組み込み系商用製品の一部（QNXとか）とMINIX３だけか
Mach3～とかも聞かなくなったし当時マイクロカーネルすげーって興奮していた身としては寂しい
でも個人で細々と作るにはマイクロカーネルのほうが手軽だよね！

…と間違ってLinux板に書いてしまった…orz
326 ：Be名無しさん：2011/12/12(月) 08:40:04.37
MkLinuxってあったよな。
Machがカーネルの奴。
327 ：Be名無しさん：2011/12/12(月) 14:42:21.42
「僕にはそれが面白かったから」の邦訳にはモノシリックと書いて在ったが
328 ：Be名無しさん：2012/03/11(日) 23:40:57.53
カーネルサンダース
329 ：Be名無しさん：2012/03/12(月) 11:27:35.32
そもそもAppleには開発力がないためにOSの開発に失敗して、
他からカーネルを借りてきた。
MacOSは～と自慢気にいう馬鹿はなんなのだ。
330 ：Be名無しさん：2012/03/12(月) 11:57:01.35
でっていう。

Darwinの何割が借り物なのか定量的に言わなきゃ、どっちも知らんがな。
331 ：Be名無しさん：2012/03/12(月) 12:25:11.88
むしろ、借り物ってのがステマだったってことはないだろうか？
Copelandは締切りに間に合わなかったけど秘密裏に開発成功していて、
でも今更どうしようかって時に、売れないのに評判だけはよかった同系の
NeXTの技術を導入したということにして汚名返上してみたとか？
332 ：Be名無しさん：2012/03/12(月) 12:55:18.23
妄想してみるなら、例えばGPL汚染が内部調査で発覚して、
結合しているブラックボックスは公開するわけにはいかなかったので、
密かにロンダリングしてたというのはどうだろう？
従来の延長路線でAPIを整理しつつ、linuxの名前を利用し汚染部分を公開して
その外部GPLコードの内製置き換えをテストさせていたとかは考えられないだろうか？
333 ：Be名無しさん：2012/03/12(月) 13:29:06.20
NSってプレフィックスが付いてるものはNeXTSTEP由来と思えばいいんじゃねーの？
Mac信者というかジョブズ信者にとってはOS XとNeXTSTEPはおんなじようなもののようだし。
334 ：Be名無しさん：2012/03/12(月) 13:32:50.58
で、何割なん？
335 ：Be名無しさん：2012/03/12(月) 13:56:21.00
NeXTとOSF/1って何割ぐらい共通なの？
336 ：Be名無しさん：2012/03/12(月) 14:39:10.49
一文字も合致しないな
337 ：Be名無しさん：2012/03/12(月) 15:28:51.48
mach2.5同士が合致しないと言われて、mach3がおんなじようなものと言われる不思議。
338 ：Be名無しさん：2012/03/12(月) 15:33:14.27
Darwinってmach3系だっけ？
NextStep由来なら2.5系じゃないの？
339 ：Be名無しさん：2012/03/12(月) 17:07:03.15
最初の奴だけ2.5で、その後何故か3になってるんだっけ？
マイクロカーネルでもないのに何の意味があったんだろう？
340 ：Be名無しさん：2012/03/12(月) 21:16:46.74
人とゴリラの遺伝子は98.25％合致するらしいから、誰かが1.75%をでっち上げれば
ゴリラをandroid化できるな。
341 ：Be名無しさん：2012/03/18(日) 21:47:06.77
Hurdっていつでるの？
あと、なんでマイクロカーネルにGnuはこだわるの？
342 ：Be名無しさん：2012/03/18(日) 22:15:53.80
Hurdはもうあるんじゃない
これ以上のものはもうでてこないんじゃない
GNUはマイクロカーネルにこだわっていないんじゃない
すでにLinuxを我が物顔で「GNU/Linux」と呼べとか行ってるし
343 ：Be名無しさん：2012/03/20(火) 09:07:45.92
マイクロカーネルにこだわってたというより、当時はフリーな選択肢がそれしかなかったんじゃないの？
machはOSF陣営が採用していたわけで、UNIXとしての実績があった。
3でマイクロカーネル化してOSコアのmach部分とライセンスが必要な部分が分離できていた。
というわけで後者の代替を作ろうと考えたんじゃない？

でもBSDが、いやよく考えてみたら気がついたらこれ殆ど原型とどめてなくね？
ってことでフリーでいいよとNet/2を出して、いやそれおらんだってことで裁判沙汰になって
FreeBSDなんか書き直しする羽目になったけど、それでもHurdより先にリリースできて、
その少し前に現れたlinuxに人が集まって、その間にUNIXの冷戦構造も崩壊して、
情報ハイウエイやら、PCはdosからwindowsの時代になるわで、大事な数年を逸して、
一体なにもたもたやってんのさ？って事になったんじゃないんだろうか？
344 ：Be名無しさん：2012/03/20(火) 10:02:37.13
ライセンスに縛られないUNIXとしては（訴訟期間はあれど）BSDがとっくに良いものをリリースしていたのに
それでもGPLにこだわって「GPLのカーネル」を欲するのがGNUたるゆえんかな
Gnu is Not UnixはUNIXに代わるフリーなシステムを作る事ではなくUNIXに代わるGPLのシステムを作る事だったと
345 ：Be名無しさん：2012/03/20(火) 17:47:37.31
>>344
いや、Net/2はLinux 0.01と同じ年で、その前年からHurdは開発始まってたらしいよ。
しかしブートできるまでに３年も掛かって、その頃にはSoundBlasterで
CD-ROMが普及していたので、リリースした時点であっという間に広まった。
逆に言えばライセンス問題があるとCDプレスに二の足を踏むわけで、
破棄だけは避けようと譲歩したんじゃないんだろうか？
まあ4.4BSD Liteベースで完全解決できた訳だけど、その隙にlinuxが入り込めた。
せめてLite移行完了までにHurdが形になっていれば、真打ち登場と言えたんだろうけど、
mklinuxとか、linuxにさえ抜かれちゃう始末だし。

mach3はGPLではないので(HurdもGNU Machの機能は使っていないんだっけ？）
GPL以外に代替があるなら完成度の低いものをわざわざ選択する意味はないよね。
346 ：Be名無しさん：2012/03/20(火) 20:28:31.80
しかしBSD on muchって何度も復活するよね
初代much(これは不完全だが) > Hurd? > dragonfly BSD
でも普及には至らないんだよなぁ
一応、NextとOSF/1は実用か?
347 ：Be名無しさん：2012/03/20(火) 22:48:47.92
っていうか、ttp://www.rtmach.org/intro-j.html
こんな面白そうなものがあったのに誰も紹介しないんだもん。

存在知らないから独自OSに走って車輪付けるところで消耗して結局エターナる
OS開発者も居たんじゃないだろうか？と、androidの作りとか見て思った。
348 ：Be名無しさん：2012/03/20(火) 23:37:11.61
１０年位前から知ってるし
独自OS作る奴は作ることを楽しんでいるんだから既存のOSはあまり関係ないだろう
逆に既存OSより良いもの（実用的な物）が欲しい奴は見込みの有りそうなプロジェクトにコミットしてるんじゃない？
349 ：Be名無しさん：2012/03/21(水) 00:29:02.80
>>348
＞１０年位前から知ってるし
それをどうやって証明するのさ？
消息不明の作者逹にアンケートでもした？

＞独自OS作る奴は作ることを楽しんでいるんだから既存のOSはあまり関係ないだろう
そういう思い込みで教えてもらえなかった連中も多いんじゃないの？
誰でも知っているような事を意外と知らなくて遠回りしたなんて話も後で結構聞くんだよな。
まあ困ってる事をきちんと言わない見栄っぱりの自業自得だけど。
350 ：Be名無しさん：2012/03/21(水) 06:50:45.20
>＞１０年位前から知ってるし
>それをどうやって証明するのさ？
>消息不明の作者逹にアンケートでもした？

10年は嘘だった
このページで知ったから5～6年前だ
http://www.bekkoame.ne.jp/ha/kuwaya/unchiku.html
各作者が知ってるかどうかは知らんし、そういう文章にはなってないはずだが？


>＞独自OS作る奴は作ることを楽しんでいるんだから既存のOSはあまり関係ないだろう
>そういう思い込みで教えてもらえなかった連中も多いんじゃないの？

なら俺OS系のWikiとかに書きこんでみたら？
その考えのほうが思い込みだってわかると思うよ
351 ：Be名無しさん：2012/03/21(水) 08:50:16.01
何が思い込みなんだ？
俺OS（だと思い込んでるの）にわざわざ別のOSの事言う奴はアンチだけってことだろ。
顰蹙を買うのは嫌なので（悪）名を売りたいのでなければ黙っていた筈。
「あまり関係ないだろう」と書かれていて、そう思っている人が居るのは事実で、
そういう人は指摘してくれないだろうから、後は２ｃｈでも見るしかないんじゃないか？
352 ：Be名無しさん：2012/03/21(水) 09:18:26.90
既存の有無というのは、モチベーションの面で関係大アリじゃないかな？
無いのでオレが作りたいと思う奴は、有ると知ったらやめたくなる。
有るので真似すれば作れると思う奴は、無いと知ったら逃亡する。
353 ：Be名無しさん：2012/03/21(水) 10:31:35.11
アジア人は全体を見て行動し、西洋人はリーダーを見て行動するらしい。
これってマイクロカーネルとモノリシックカーネルの考えそのものじゃないだろうか？

でも実際の区分はぶっちゃけ、ランプの魔神を大衆の願いを叶えてくれる仏のようなお上と考えるか
市民の下で働く一騎当千の公僕と考えるかという違いの話になってるんだよね。

結局、文民統制にハードウェアによるカーストを利用するかどうかで、
性悪説なら緊箍児が必要だし、性善説なら不要って話に矮小化されちゃってる。
354 ：Be名無しさん：2012/05/05(土) 17:30:16.00
タンデンバウムって菩提樹だっけ。
355 ：Be名無しさん：2012/11/10(土) 00:29:27.85
カーネルサンダース
356 ：Be名無しさん：2012/11/10(土) 07:53:51.30
ドライバーに対してはスタックマシンとして振る舞うＶＭスタブが一番堅牢。
ＶＭのサーフェス側のサービスレベルをどの高さに設計するかだけの話。

と言うのも、どうしてもソフトウェアカーネルを設置したいのであれば、あれこれ調整された機能の調製を求める内にモノリシックに行き着くのは当然であるから。

しかし、そもそもソフトウェアカーネルなんぞハードウェアの仕様を覚えられない難読症児の戯言だとする者はマイクロカーネル乃至マイクロコードを指向する様になる。

最速は常にハードウェア、以上。
357 ：Be名無しさん：2013/03/18(月) 11:05:54.41
amiga osはマイクロカーネルだったのか
「マイクロカーネル風」って表現もあるし、メモリ保護なし・直接関数コールとかスゲーけど別にいいよね
あとMacOS9の下にマイクロカーネルがあったのも知らんかった
358 ：Be名無しさん：2013/04/07(日) 20:56:05.43
マイクロカーネルもバズワードで明確な定義が無いのだから風も何もない。
359 ：Be名無しさん：2013/04/07(日) 21:53:15.73
基本的には「プロセス/ファイルシステムやデバイス・ドライバー等の大きな機能を除いた基本機能のみ」のカーネルって事だけど
・基本機能とは？（タスクスケジューラーやメモリアロケータも含まない！とか仮想アドレス＋メモリ保護も必要！）
辺りの解釈が不明確というか各人で分かれてる感じ
スケジューラーとメモリアロケータは含まないけどメモリ保護は必須みたいな意見も見た気がするし・・・
360 ：Be名無しさん：2013/04/08(月) 11:33:46.81
メッセージパッシング機能とディスパッチャが最低限でしょ。
361 ：Be名無しさん：2013/04/08(月) 11:52:03.75
メッセージパッシングの方式（amigaは関数テーブル呼び出しだそうで）をどう定義するか
他の機能（スケジューラーやメモリ管理）がのっているものはマイクロカーネルじゃない！と原理主義に走るか（ゆるくし過ぎるとなんでもかんでもマイクロカーネルと言えるようになるし）
線引は難しいですよね
362 ：Be名無しさん：2013/09/21(土) 14:17:11.24
はい
363 ：Be名無しさん：2013/09/28(土) 14:09:02.83
CISC RISC
と一緒で完璧にどちらかに分類できる実装なんか今時存在しない
364 ：Be名無しさん：2014/05/26(月) 21:07:08.62
質問です

マイクロカーネルについて勉強中です
マイクロカーネルはプロセス間通信を使用してサービスを受けると理解しました。
これはアプリがシステムコールを呼んだ際、自分のコンテキストは待ち状態になり
サーバーで待ち状態だったプロセスが解除されてコンテキストがバトンタッチ(?)するという感じでしょうか？

もしそうならば、たとえばサーバーのプロセス(スレッド)が１つしかない場合、複数アプリから同時にサービスコールが呼ばれると
１つだけ処理されて、残りは待たされるのでしょうか？

あいまいな質問ですみません。
365 ：Be名無しさん：2014/05/28(水) 11:13:08.20
YES
物理ディスクのアクセス等は（キャッシュ等は除き）そもそも並列動作できないから普通に待ち行列行き
OS機能全体を１つのスレッド(プロセス)で処理するような実装なら誰かがシステムコールを実行中は他は待たされる
たいていはサービス毎に処理スレッド(プロセス)を走らせるから競合しなければ並列動作する(ディスクIOとコンソール出力とか…)
366 ：364：2014/05/28(水) 19:39:59.67
>>365
よくわかりますた
ありがとう！
367 ：Be名無しさん：2014/10/16(木) 11:33:06.28
マイクロカーネルばんざーい！
マイクロカーネルとして良いのはなんだろう
L4？　QNX？　MINIX？　OSE？
OSの話題が無くてつまらん

モノリシックはNetBSD最高
368 ：Be名無しさん：2014/10/17(金) 17:36:01.72
最新の Minix は マイクロカーネル + NetBSD だし
369 ：Be名無しさん：
はい…
それはそれとして本家NetBSDの移植性を高めた設計も好き