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

マイクロカーネル vs ..

2:Be名無しさん
03/10/12 15:40.net
おいおいおい・・・2getかよ

3:2
03/10/12 15:40.net
初2getｷﾀ━━(ﾟ∀ﾟ)━( ﾟ∀)━( ﾟ)━( )━(ﾟ )━(∀ﾟ )━(ﾟ∀ﾟ)━━!!!!!

4:Be名無しさん
03/10/12 15:41.net
このスレはマジに語れるのか？？？？？？

5:Be名無しさん
03/10/12 15:42.net
>>3
晒し上げ

6:LC
03/10/12 15:47.net
マイクロカーネルが、モノリシックカーネルより、いくつかの点で
「よい」とか言う主張だって、いい加減さは同じだよ。

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

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

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

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

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

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

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

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

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

7:4
03/10/12 15:48.net
組み込み向けにはマイクロカーネルがいいと思われ
モノリシック＆モジュールは便利だが、モジュールがこけると
カーネルごとこけるのがいただけない

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

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

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

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

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

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

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

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

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

10:1
03/10/12 15:53.net
Machは複雑になりすぎてるという論調はあるみたいだが、OSの研究
としては高く評価されているのでは？

11:Be名無しさん
03/10/12 15:56.net
> 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.net
確かに理論だけでは語れない部分が多々あるのは確か。
実際に日本でOSの開発をしている開発者はどう思うので
しょうかねぇ

13:LC
03/10/12 16:05.net
マイクロカーネルの例として、Minix, Mach, WindowsNTについて。

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

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

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

14:LC
03/10/12 16:07.net
Minixで、MMUを使わずにマイクロカーネルを採用する意図が、私には全く
理解できない。

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

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

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

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

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

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

15:LC
03/10/12 16:10.net
保護するために複雑になる例 : メモリ確保

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

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

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

次の理解は間違いです:

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

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

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

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

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

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

17:LC
03/10/12 16:15.net
参考:

Linuxの作者もマイクロカーネルの弱点を指摘:
URLﾘﾝｸ(www.linux.or.jp)

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

18:LC
03/10/12 16:17.net
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.net
>「特にIntel系のような奇妙なCPUに依存したオペレーティングシス
>テムを新たに書くことは、基本的に間違っていると指摘しているだけ
>です。」

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

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

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

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

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

20:Be名無しさん
03/10/12 16:21.net
>> 16

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

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

ご冗談でしょう?

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

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

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

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

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

23:LC
03/10/12 16:24.net
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.net
LCって誰？OSの開発者？

25:LC
03/10/12 16:28.net
>>21
そもそも、OS研究に限っては、大学でも、大して「アカデミック」では
無いと思う。全然大したことやってない。

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

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

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

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

26:Be名無しさん
03/10/12 16:31.net
>>24
そうだよ。ってゆーか、知らんかったんかい。（ｗ

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

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

28:Be名無しさん
03/10/12 16:35.net
>>14
タネンバウムが本当にやりたかったのはMinixみたいな糞じゃなくてAmoebaだったんだけどなー
UNIXの次は分散OSってことでPlan9やAmoebaが出てきた
PS3によってようやく分散OSが市民権を得るって時代になってんだけどなー

29:24
03/10/12 16:42.net
>>26
知らんかった。詳しく教えてちょ！

30:Be名無しさん
03/10/12 16:45.net
>>29
ここに書いてあるのは全部コピペだよ
ｽﾚﾘﾝｸ(os板)

本人はもう2chからは手を引いたと言われている
ちょうど今日、彼のスレが幕を閉じた...
ｽﾚﾘﾝｸ(os板)

31:Be名無しさん
03/10/12 16:46.net
分散OSをさらに発展させるのは次世代プロセッサCELLになり得るか。
ちなみに、CELLで動くOSはモノリシックカーネルになるのだろうか、
それともマイクロカーネルか？

32:Be名無しさん
03/10/12 16:49.net
マイクロカーネルが性能面で劣ることはタネンバウム自身
認めているので、そこを突いても無駄。

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

33:29
03/10/12 16:49.net
>>30

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

34:29
03/10/12 16:52.net
>>33
だから本人じゃなくてどっかの厨が過去ログからコピペしてるだけっつってんじゃん

35:30
03/10/12 16:53.net
失敬。
>>34の名前はミスです。
本当は30でした。

36:Be名無しさん
03/10/12 16:54.net
拡張性は、理論的にはマイクロカーネルがの方が上のはずだが、
実際、モノリシックカーネル＋モジュールという形式の方が上
に見えるが、いかがでしょう？

37:33
03/10/12 16:55.net
>>34
あ、そういうことね（＾＾；

38:Be名無しさん
03/10/12 17:24.net
コピペであれ何であれ、
LightConeが一番しっかりしたこと書いてるように感じるのは気のせい？

39: ◆1haVRB54HY
03/10/12 17:29.net
>>38
気のせい。(Linusさん信者だったのね。ふーん（´_ゝ｀）
つか、どっかでNWSOSをマイクロにしたいとか逝ってなかった？

40:Be名無しさん
03/10/12 17:30.net
　∧||∧
（　 ⌒ ヽ　>>38
　∪　　ﾉ　お前が感じている感情は精神的疾患の一種だ。
　　∪∪　鎮める方法はない。逝ってよし。

41:Be名無しさん
03/10/12 17:32.net
>>39

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

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

42: ◆1haVRB54HY
03/10/12 17:41.net
>>41
なんか他所でも逝ってた様な気がする。(つか、何が"かなり高速"だよ。(w

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

44: ◆1haVRB54HY
03/10/12 18:03.net
>>43
そんなことしたいので、とりあえず図書館でまた本借りてきますた。

45:Be名無しさん
03/10/12 18:35.net
>>44
できない奴はできないよ。
センスが無いんだから諦めろ。

46:Be名無しさん
03/10/12 19:25.net
Minix使ったことある人っている？

47:Be名無しさん
03/10/12 19:34.net
オブジェクト指向との親和性でマイクロカーネル優位。
これを生かすためにはオブジェクト指向言語が不可欠。
それもObjective-Cみたいな原始的なものがベスト。

48:Be名無しさん
03/10/12 20:55.net
>>47
Darwinマンセー、だね！

49:Be名無しさん
03/10/12 21:45.net
>>47
しかしパフォーマンスが悪いわな。
プロセス間通信によるオーバーヘッドをどう回避するか。

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

51:Be名無しさん
03/10/12 22:41.net
>>50
あれってモノリシックだったんじゃ？

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

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

54:Be名無しさん
03/10/12 23:15.net
>>52
ということはDarwinではモノリシックに軍配が上がったということ
ですよね？

55:Be名無しさん
03/10/12 23:16.net
>>53
なんか必死に誘導しようとしているな

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

57:Be名無しさん
03/10/13 00:11.net
いまさら、マイクロカーネルかモノリシックカーネルかで優劣競っても意味ないんじゃない？
RISC vs. CISC 論争を思い出すよ。

58:Be名無しさん
03/10/13 00:12.net
>>54
現状では、ね。

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

59:Be名無しさん
03/10/13 00:13.net
>>57
CPUが高速になった現代では意味のない議論だってことか？

60:Be名無しさん
03/10/13 00:13.net
てか、UNIXが元々モノリシックってことか。

61:Be名無しさん
03/10/13 00:15.net
>>59
同じことはJavaとか.NETとかのバイトコード方式にも言えるね

62:Be名無しさん
03/10/13 00:18.net
>>58
現在の最高性能だけを視野に入れるならマイクロカーネルが有利だろうね。
最高性能だけを視野に入れるならだが。

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

64:Be名無しさん
03/10/13 06:53.net
最高性能が欲しいならﾓﾉﾘｼｯｸのほうが絶対有利。
タスクスイッチしなくていいから。
(だからとてLC氏のDOSﾏﾝｾｰはなんか違うのだが)

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

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

65:57
03/10/13 07:56.net
>>64
そうだね。デバイスドライバのモジュールはマイクロカーネルのとは関係ないですね。

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

66:Be名無しさん
03/10/13 10:31.net
>>64
>>62は最高性能のマシンだけって意味だと思うけど。

67:Be名無しさん
03/10/13 16:54.net
>>58
確かにCMTでもＳＭＰでも、マルチプロセッサになってくると、
マルチカーネルみたいなのに走りたくなってくる。

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

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

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

68:Be名無しさん
03/10/13 16:56.net
s/モノシリック/モノリシック/
なんでかしらないが、素でよく間違える('A`)

69: ◆1haVRB54HY
03/10/13 17:03.net
月刊ASCIIのセイで今の今までずーと"モノシリック"と思ってますた。。。

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

71:Be名無しさん
03/10/13 19:46.net
CMT : Coarse grained MultiThreading
CMP : Chip-level MultiProcessing
で良かったでしょうか？

72:Be名無しさん
03/10/13 20:11.net
>>71
CMT: Chip MultiThreading
が普通じゃないかな？

73:71
03/10/13 20:58.net
>>72
THX!

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

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

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

75:Be名無しさん
03/10/15 15:05.net
>>74氏はご存知かと思うけど、「だったらプリエンティブカーネルに
すりゃいいじゃん」、と勝手に補足しておこう。

作るの地獄だけど。

76:Be名無しさん
03/10/15 15:24.net
プリエンプティブとリエントラントを混同してる痛い香具師がいるな

77:Be名無しさん
03/10/15 15:38.net
未だにカーネル丸ごとロックなOSって多いよね。
割込ロックだけにするとドライバとかプロトコルスタックとかも
全部書き直し必要だからしかたないと言えば仕方ないかもしれないけど。

78:Be名無しさん
03/10/17 04:02.net
それわおめーだっつーの>>76

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

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

79:Be名無しさん
03/10/17 09:59.net
どうでもいい話かもしれないか超漢字はマイクロカーネル採用らしい

80:LightCone ◆sSJBZiod2E
03/10/17 20:33.net
(^_^;

81:Be名無しさん
03/10/17 23:41.net
未来指向派 vs リアリスト、みたいなもんだろ。未来指向派がマイクロカーネル。

82:Be名無しさん
03/10/18 11:09.net
モノリシックカーネルで
プリエンティブマルチタスクで、なおかつ
リアルタイムOSなんて可能なんですかね？

83:Be名無しさん
03/10/18 11:26.net
Lﾀﾝ、OS作り

や　　ら　　な　　い　　か　　？

84:Be名無しさん
03/10/18 15:08.net
WinNTは実用的なマイクロカーネルだね！

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

85:Be名無しさん
03/10/18 15:37.net
GNU Hurd は Windows の夢を見るか？

86:Be名無しさん
03/10/18 16:44.net
>>84
前から崩れてる。
NT3.51のころはきれいだったんだが…

87:Be名無しさん
03/10/18 19:15.net
カトラー vs ストールマン

88:Be名無しさん
03/10/18 22:38.net
BSD Conでこのスレの話題が出てきて藁他

89:Be名無しさん
03/10/20 23:22.net
>>82
「リアルタイムOS」を定義汁。
話はそれから堕。

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

90:Be名無しさん
03/10/21 03:49.net
>>82
可能だろ。

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

91:Be名無しさん
03/10/21 03:58.net
すまん間違えた。
タスクのスケジューリング方式。

92:Be名無しさん
03/10/21 06:20.net
その「タスク」にカーネルのお仕事が入るかどうかで
>>75のような地獄を見るかどうかが決まるわけで。

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

93:Be名無しさん
03/10/21 17:38.net
>>74の「SMPだとmutexのコストが増加する」っての解説きぼんぬ。

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

94:Be名無しさん
03/10/21 19:39.net
>>89

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

95:Be名無しさん
03/10/21 19:50.net
>94 実現可能性を知りたいなら作ってみれば？

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

96:Be名無しさん
03/10/22 00:15.net
しかしｶｷｺしてる椰子で「リアルタイムＯＳ」がどんなもんか
分かてるのはどのくらいいるんだ？

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

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

97:Be名無しさん
03/10/22 02:22.net
>>96 Lなんとかはどうでもいいよ。

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

98:Be名無しさん
03/10/22 16:43.net
デスクトップでリアルタイムOSってメリットあるの？

99:Be名無しさん
03/10/22 17:13.net
どうなんでしょう。
人間相手に1msレベルの応答速度はいらないし。

100:Be名無しさん
03/10/22 17:13.net
>>98
CD焼きながらのマルチタスクに強い
そんなのは過去の話だというのは甘い
DVD8倍速焼きなんかだと他のアプリを起動してなくてもとりこぼす

101:Be名無しさん
03/10/22 17:15.net
>>100
あーなるほど。
確かにP4 3G HTでもエンコしながら8倍で焼くとボロボロだね。

102:Be名無しさん
03/10/22 17:20.net
>>101
そんなことがしたいなら素直に2台買うかDual Xeon(HT)にしろや

103:Be名無しさん
03/10/22 18:45.net
>>98
ある。
マウスクリックしてから反応が返るまでの時間を保証できる。

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

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

104:Be名無しさん
03/10/22 21:23.net
>>103
アプリが応答する時間までは保証できないんでは？

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

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

106:Be名無しさん
03/10/23 21:22.net
>>105
保証できないようなのはRTOSとは言わんが何か。

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

107:Be名無しさん
03/10/23 22:48.net
ﾘｱﾙﾀｲﾑ性はﾃﾞﾊﾞｲｽﾄﾞﾗｲﾊﾞでだけ保証されてればｲｲﾔ
と思てる椰子もいるんでないかな。
(ﾘｱﾙﾀｲﾑLinuxの大半はそんな実装だし)

108:Be名無しさん
03/10/24 09:15.net
> Soft RTOSなら必ずしも保証できん、ならわからんでもないが

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

109:Be名無しさん
03/10/24 21:41.net
かなり頭の悪い香具師が厄一名いるな

110:素人様のお通りだ
03/10/27 21:12.net
　マイクロカーネルが遅いというのは聞くけど、BeOSってマイクロカーネルではなかった？
(どっかにそう書いてあった)あれは速かったと思うんだけど。
　それともここの人たちが言う「速い」「遅い」って体感速度は別の話なの？
　教えて偉い人！

111:偉くない人
03/10/28 03:56.net
限界速度の話。

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

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

112:Be名無しさん
03/10/29 18:07.net
漏れは音楽製作をＰＣ上でやってるんだが、最低1msの精度を出したかったりする。
そういうのに対応したOS欲しいな。BeOSが有力だったんだがZetaがどうなることやら

113:Be名無しさん
03/10/29 20:28.net
>>112 漏れが作ってやるよ

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

114:Be名無しさん
03/10/29 20:52.net
和音のタイミングを合わせたいとか。

115:Be名無しさん
03/10/30 15:18.net
114はスルーで

116:Be名無しさん
03/10/31 08:52.net
たとえば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.net
自分の無知を指摘されて「攻撃的」だといい、
「うんざり」だとか「頭の中をクリア」しろなどという暴言まで書き込んでおきながら、
２ちゃん以下の話だと判明したら何も言わずに逃げましたか？

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

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

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

119:Be名無しさん
03/11/02 00:46.net
>>117
それはOS-wikiのネタだろゴルァ（ｗ

120:Be名無しさん116
03/11/02 13:47.net
>>118 これはMIDIの場合ね。ノンリニアの場合はもうちょっとシビア。

121:Be名無しさん
03/11/02 22:43.net
>> とはいえn重和音を出すならn倍の時間がかかる
ので、高級なMIDIコントローラは複数のMIDI OUTがある。

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

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

122:121
03/11/02 22:52.net
当然だけど
RTOSを使えば魔法のように時間精度が精密になる

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

123:Be名無しさん
03/11/03 14:31.net
>>119
K氏の定義は通説より狭い感じがして違和感があるが、一応筋は通っているな
名無しは逝って良し
もなか氏のカキコが自分の味方だと思っているしな

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

125:Be名無しさん
03/11/03 17:30.net
名無しの支離滅裂さは凄いな。

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

126:Be名無しさん
03/11/03 17:54.net
age

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

左がサンデーモーニング　右が直後の番組サンデージャポン
URLﾘﾝｸ(yucarimint.hp.infoseek.co.jp)

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

128:Be名無しさん
03/11/03 23:11.net
>>124
カーネルのデバッグとか。

129:Be名無しさん
03/11/04 08:48.net
「性能の悪いリアルタイムOS」もあれば
「性能のいい非リアルタイムOS」もあるわけで。
その辺がわかってない厨って結構いるよね。

130:Be名無しさん
03/11/04 12:13.net
ここ厨房板だから、まともな板へ行って話続けない？

131:丸本
03/11/04 13:03.net
厨房板に相応しいレベルの話ししかでていないわけだが

132:Be名無しさん
03/11/04 13:25.net
で、まともな板って何？

133:Be名無しさん
03/11/04 20:02.net
Wikiの必死な議論好きについて…

URLﾘﾝｸ(www.tron-net.gr.jp)
URLﾘﾝｸ(www.tron-net.gr.jp)

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

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

134:Be名無しさん
03/11/05 00:53.net
>>111
LonghornでGDIもカーネルの外側に戻るみたいだね。

135:Be名無しさん
03/11/05 14:30.net
>>124
> マイクロカーネルの方がいい場合って例えばどんな時？

保守性を考えるとき。

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

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

137:Be名無しさん
03/11/06 04:11.net
いまだに名無しは一人だと思てる椰子ﾊｹｰｿ

138:Be名無しさん
03/11/06 09:50.net
必死ですね

139:Be名無しさん
03/11/06 12:28.net
必死です

140:Be名無しさん
03/11/06 16:45.net
>>139
藁田

141:Be名無しさん
03/11/06 19:38.net
Kタンも追い詰められて必死だね。
自分の間違いを認められないってダメじゃん。
やっぱ、OS議論は遠くで眺めるに限る。

142:Be名無しさん
03/11/06 22:23.net
ウソつきと正直者系も定番クイズがわんさかあるよね。

143:142
03/11/06 22:25.net
誤爆しますた。スマソ

144: ◆1haVRB54HY
03/11/07 00:21.net
>>141
我が師を冒涜するとは万死に値する。謝罪しる！

145:Be名無しさん
03/11/07 00:43.net
>>144
おっ！男だねぇ。

146:Be名無しさん
03/11/07 02:12.net
>>141
いつものことだ。
もう少し勉強した方がいいと思うんだけどねえ。
俺OSに籠るなら必要ないのかもしれないが。

147:141
03/11/07 02:15.net
>>144
お前らには見えないかもしれないけど今、泣いて謝罪してます。

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

148:141
03/11/07 02:16.net
>>144
お前らには見えないかもしれないけど今、泣いて謝罪してます。

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

149:141
03/11/07 02:18.net
>>146
そうだね。

150:Be名無しさん
03/11/07 04:04.net
なんだ、K氏はちゃんと間違いを認めているじゃないか。
間違いを指摘できなかった奴（>>141）が偉そうにほざいているのか。
自分じゃ指摘できないもんな、遠くで見ているしかないよな（藁

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

151:本物 ◆1haVRB54HY
03/11/07 15:42.net
>>144=偽物。
しかし、ほぼ同意。

152:Be名無しさん
03/11/07 16:19.net
自分の都合のいい時だけ本物言われてもなあ・・・
俺からみたらどっちも同じだろ

153:Be名無しさん
03/11/07 22:35.net
>>147-148
君も漢だね！

154:Be名無しさん
03/11/08 01:53.net
結局、図書館でホコリかぶってるような本を読んで、
「これがマイクロカーネルか！！」って感銘を受けても
今流のマイクロカーネルは、それとはだいぶ違うって事？

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

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

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

158:Be名無しさん
03/11/08 22:12.net
>>157
どうちがうの？具体的に説明してみて

159:Be名無しさん
03/11/09 03:48.net
むかーしむかし、王子の発言にこんなのが。

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

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

161:ITRON名無しさん ◆4WD27e3i1o
03/11/10 10:05.net
> マイクロカーネルって要は

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

162:Be名無しさん
03/11/10 11:32.net
>Machをもってマイクロカーネルを推察するのもどうかと
いや、だからMach的なモデル以外のものがあるなら教えてと書いてあるじゃん。

次ページ