microkernel

マイクロカーネル一般論 †

• とりあえず議論ページ第一号を目指します。
• ここではマイクロカーネルにまつわる議論を扱います。

Kが知り得た知識 †

• マイクロカーネルというのは、機構（仕組み）の名前であって、その背景にどんな目的があるかということとは無関係。
• どんな機構：
  • とりあえずカーネルは小さい。たいていアプリとしては実装できない部分だけを持つ。もっと分かりやすく言うとカーネルモードで記述しないとまずい部分。
  • カーネルから追い出されたOSのサービスは、タスクとして記述される？関数とかでもいい？？？
  • メッセージ機構が不可欠？？？
    • でもこれがメッセージを交換する方法だと各OSで定義さえできれていれば、とりあえずメッセージの具体的な実装方法などについては規定されていないような感じなので、何をもってメッセージ機構というかは厳格ではなさそう。
  • カーネルから分離したサービス群は十分に分割されるのも要請される？それとも、マイクロカーネルはカーネルの機構であって、サービスの機構については言及しない？？？
  • 高速化の手段としてサービスがカーネルモードで走るなんてこともあるらしい（それはできると思うけど、どのくらいの効果があるだろうか？？？）。

• この機構を選択すると、どんな効用があるか：
  • サービスを交換することで、同じカーネルで違うOSを作れる。
  • （ダイナミックに交換できるようにしておけば）OSを終了することなく複数のOSを走らせたり、入れ替えたりできる（と思う）。
  • （メッセージがCPUの壁やネットワークを越えられるように実装した場合に限り）OSサービスを分散処理可能。
  • この3つも、マイクロカーネル機構じゃなくてもできる気はする（そりゃまあ、スマートじゃないかもしれないけどね）。
  • （マイクロカーネルにしかできない、といえるようなものは何だろう？）
  • カーネルのデバッグが楽（小さいから）。

• この機構でも他の機構でも得られる効用：
  • 機構と運用ポリシーが分離できる（そもそも機構はポリシーから分離している）。
    • 運用ポリシーの例：安全第一、高速優先、など

• 結局ふんだんにモジュール化されたモノリシックとどう違うの？：
  • この見解に立てば、差はない。
  • モジュール化にもレベルはあるが、十分に細分化されていて（＝カーネルも十分に小さくなっていて）、ダイナミックに交換できて、モジュールの組み合わせかたに十分な自由度があれば、それはもはやマイクロカーネルな気がする（しかもマイクロカーネルとしても、上等というか高級な部類に入りそうだ）。
  • モジュール化を考えているなら、マイクロカーネル・モノリシックカーネルというのはあまり本質的な分類ではなさそう。単にモジュール化の度合いを問題にしているに過ぎない。
  • たぶん最初の頃のマイクロカーネルはもっと要請が多かったんだと思う。そのせいで遅かった。その要請がなくなって、モジュール化だけが残り、つまりKが以前主張したところの、「ほとんど意味のない言葉」になったんだと思う。モジュール化があるラインに達したら、「モジュール化したモノリシックカーネル」「マイクロカーネル」のどちらにも呼びうることになる。
  • つまりマイクロカーネルは最初さまざまな主張を持っていたけど、何がベストなのかを追求していった過程で、余計な要請があったことが判明してそれを取り下げてきたわけだ。マイクロカーネル論者がモノリシックを批判していたが（もちろんモノリシック論者もマイクロカーネルを批判したが）、その論拠は結局なくなって、モノリシック派でも効用を認めていたモジュール化だけがマイクロカーネルに残ったことになる。そういう意味でマイクロカーネルは死んだといえるだろう。
    • だからKはこのページ以外では、マイクロカーネルという語を避けて話をしようと思う。普通に「モジュール化しています」っていうほうが、的確だと思うから。
    • これをshさん的な観点で見ると、マイクロカーネルはモジュール化以外のマイクロカーネル性も「捨てうる」ことで、なんにでもなれる可能性を獲得した、ともいえる。この観点に立てば、マイクロカーネルは高度にモジュール化したモノリシックカーネルを「吸収合併」したともいえる。
    • どっちにしても、論点を取り下げたのはマイクロカーネル派であって、モノリシックカーネル派ではない（＝いうなれば、モノリシックカーネルがマイクロカーネルの特徴を取り入れたのではなく、マイクロカーネルがモノリシックカーネルの特徴を取り入れたのである）。
    • どっちにしても、マイクロカーネル固有の特徴はもはやないといってよく、そういう意味ではほとんど役に立たない機構区分ではある。
  • ・・・と思ったら、垂直水平という分類案が残っていた。これが分かれば、違いが分かるかもしれない。
    • もなかさんのおかげでだいぶ分かった。垂直水平というのは、モジュール化の方針の違いだと言ってよいと思う。メッセージをやり取りする際に、やたらと多くのモジュールを経由しなければいけないのが垂直で、（理想的には）カーネル以外には全く経由しないというのが水平。理想的な垂直構造では、全てのモジュールがレイヤのような関係になり、一番上からのメッセージが一番下まで行くみたいに、一つのメッセージを伝達するために全てのモジュールを経由するような状態になるだろう。
    • 垂直水平という分類はナンセンスだと思った。が、暇がなくて見解が書けないでいる。年末までには時間を作って、どうしてナンセンスだと思ったかを含めて書きたいと思っている。

Kの誤解 †

• 意見をくださったみなさまありがとうございます。Kは見解を修正・整理しました。
• さらに大幅に修正しました。Kは勘違いをしていることが分かりました。僕の間違いを的確に考察して指摘してくれた、Gakuさんに感謝いたします。

• 問題の要点：
  • Kはマイクロカーネルが何のためのものか、という「目的」にこだわりました。最初からそうでした。目的が分かれば、理解できるという考えでした。マイクロカーネルは手段だと思っていたのです。
  • これが最大の失敗でした。そもそもマイクロカーネルは仕組みの名前であって、手段の名前ではないのです。つまり、同じ仕組みであっても、時代によって利用目的が変わりうるのです。
  • それなのに、目的を問い続けてしまいました。指摘されるまで、自分の愚考に気づきませんでした。この方向に議論をミスリードしてしまい、大変申し訳ないです。
  • 「ポリシーと機構の分離」が論点になったこともありましたが、そういうレベルに入る以前のところで間違っていたわけです（この話題も結果的にはミスリードだったように思います。これはマイクロカーネル機構固有の特徴ではなく、他の機構でも可能なことなのに、マイクロカーネル固有であるかのような記述がありますので）。
  • 「マイクロカーネルは手段ではなく機構である。そこに一貫した目的を求めた議論をしてもしょうがない。それぞれがそれぞれの思惑で採用していいのだから」これこそ僕が理解するべきことでした。もちろん、ミスリードであっても何も得られなかったということではありません。色々勉強はできました。
  • 仕組みそのものは何に使ってもいいので、最初からポリシーとは分離しているべきでしょう。マイクロカーネルという機構に、「ポリシー分離の観点」というものはないのです。Kの主張であった、そんな使い方（＝運用ポリシー）はおかしいという指摘こそおかしいのです。

（以下、間違っていたころの見解）

• いずれ引っ越すべきと思うのですが、議論の流れが分からなくなるのはよくないと思うので、削除する予定はありません。

• マイクロカーネルというのはカーネル構成法の一つで、カーネルモードで走らなければいけない部分だけをカーネルとし、そのほかのOSサービスをユーザモードで走らせるというものである。
  • この目的は次の通り：
  • OSサービスにバグが残っていても、カーネルは破壊されることがないようにする
  • デバッグのしにくい、カーネルモードで動くコードを最小にする
• 開発のしやすさ、拡張のしやすさはあまり関係がない。なぜなら、モノリシックカーネルでもデバッグ時にユーザモードを活用するという手法はありうるからである。
  • マイクロカーネルでは、運用時にOSサービスがユーザモードで走ることを前提にする。もし「ただの開発手法」であるとするなら、ユーザモードで走ったときに多少遅かろうとも、それはデバッグモードみたいなものなのだから、克復するために苦労する必要はないのである。・・・マイクロカーネルは、ユーザモードで運用することを前提にしているからこそ、ユーザモードでも速くできるような（遅くならないような）研究が多くなされたのである。
  • もちろんだからといって、カーネルモードでサービスを走らせられるようになっていてはいけないということではない（むしろ選べるようになっているのはいいことである）。でも、ユーザモードで運用しないのなら、何のためのマイクロカーネルなんだろうとは思う。むしろ最初からカーネルモードで走らせることを前提にしているモノリシックのほうが速そうな気がする（もっとも、遅い速いはマイクロかモノリシックかよりも他のファクターで左右されるので、一概に言い切ることはできないが）。
  • 運用時にOSサービスのほとんどをカーネルモードで走らせることを前提にしているのが、モノリシックカーネルである。開発時にユーザモードを利用できるようになっていることはありうるが、モノリシックカーネルOSにとってはこれは運用時の状態ではないので、たぶんこの状態での問題解決（たとえば高速化）はあまり関心がないだろう。
  • どちらもターゲットにしている状態での問題解決が優先される。・・・どっちもターゲットにするような八方美人や、いくつかのサービスはカーネルモードで、いくつかのサービスはユーザモードで、のようなミックス型は「どちらでもない」に分類する。
• マイクロカーネルはカーネルのバイト数の大小とは全く関係ない。
• マイクロカーネルはOSのモジュール化とも関係がない。
  • サービスがモジュール化されたマイクロカーネルがほとんどであろうが、モジュール化しないマイクロカーネルも構築可能だし、だいいちモノリシックカーネルであってもたいていはモジュール化している。
  • それなのに、モジュール化することがマイクロカーネルだと思っている人がときどきいて言葉を誤用していることがある。
• マイクロカーネルでなければモノリシックだ、ということにはならない。どちらにも分類しかねるケースは数多くある。
• 結局何が「マイクロ」なのかというと、カーネルのバイト数ではなく、カーネルの機能でもなく、カーネルモードで動作する部分、なのである。
  • 一番守りたいのはカーネルである。もちろん、サービスAのバグがサービスBを破壊しないことも重要であるし期待されるが、これらはカーネルが死なないでこそ意味のあることで、カーネルが死ねば他のサービスが生きていても何にもならない。
  • サービスをどのように組み立てるかは（つまりどの程度分割するかは）、サービスを作る人に任されている（と、Kは解釈している）。
• 理想としては、CPUがカーネルモード（特権レベル）で実行される時間が短ければ短いほど、マイクロカーネルとしてのできは良いといえる。
  • もちろんそのせいで頻繁なカーネルモード←→ユーザモードの切り替えが起きて、効率は多少落ちるかもしれないから、OSとしてのベストな設計としては、この理想の追求をゆるめるほうがいいこともあるかもしれない。しかし、一番最初の目的に立ち返れば、これはマイクロカーネル達成率、とでも呼べる指標になりうるだろう。
• カーネルモードは考えようによってはとても危険である。どこでもアクセスできてしまうのだから、バグがあったら致命的になりやすい。それに対し、ユーザモードでは限られた部分にしかアクセスできないから、仮にバグがあったとしても、被害は限定される。またバグによる不適切なアクセスがランダムなアドレスに起こるとすれば、アクセスできる範囲が狭い分だけ、ユーザモードであるほうがバグ発見率は高い。
  • カーネル自身は自分で自分の身をまもらなければいけない。カーネルモードで走るから、ユーザモードほどの保護は当てにできない。だからめいいっぱい小さくして、バグ残存率を下げる。
• ページングのみのシステムでマイクロカーネルを実現した場合（つまりセグメンテーションを用いない場合）、ユーザモードで走る複数のコードが、同じページ空間にあるのは、マイクロカーネル的思想としてはあまりよろしくない。
  • たとえば、アプリとDLLがあり、アプリがDLLを呼び出す場合を考える（もちろんDLLでなくても、ユーザモードで走る任意のサービスであってよい）。
  • OSの設計として、アプリとDLLを同じページ空間に配したいと考えるのは妥当ではある。それは呼び出しオーバヘッドを減らせるからである。その場合は、当然アプリもDLLもユーザモードでアクセスできるように設定されるだろう。
  • そうなると、アプリにバグがあった場合、アプリは例外を発生させることなくDLL用のワークエリアを破壊できることになる。これはマイクロカーネル的な思想では、嘆かわしい事態である。バグを発見しやすくするためにユーザモードを活用しているのに、自分に直接関係ないアドレスへのアクセスが副作用的に許可されてしまったため、バグの発見が困難になってしまう。
  • 逆も当然ありうる。DLLにバグがあればアプリのワークエリアを例外なしに破壊しうるわけである。これは多少の実績のあるDLLとかだと、DLLを疑うことを忘れがちな分だけ、よりいっそう事態は深刻である。
  • そうなると必然的にアプリとDLLは別空間に配するべきだろう。パラメータ渡し等でオーバヘッドは多少増えるかもしれないが、これは仕方ない。
  • ちなみにKは、セグメンテーションを活用することで同じページ空間にあっても保護を期待できるから、ページ空間の大量生産と頻繁なページ空間切り替えコストを回避できると考えており、それゆえにセグメンテーションが大好きである（純粋なマイクロカーネルには興味がないにもかかわらず）。
  • この観点で、WindowsやLinuxがセグメンテーションを積極的に利用しないのは残念である。

• （旧見解）
  • 作りやすくするため、拡張しやすくするための開発方針。---この点は違う
  • カーネルを小さくして、追い出せるものは全てユーザモードに追い出す。---この点は同じ

他の人たちの見解 †

• （Kがまとめました。間違っていたら、「サービスがカーネルモードで走ってもマイクロカーネルだと思う人たち」のところで指摘してください。修正します。）

• LCさん：
  • カーネルの保護こそ第一という点では誤解してた頃のKと完全一致。しかしサービスをユーザモードにするというだけでは不十分で、プロセス（タスク）として独立させるべきだと主張。その根拠はアドレス空間の分離にある。
    • （アドレス空間の分離は、セグメンテーションを使うとかすればプロセスじゃなくてもできるから、そこまできつい定義にこだわらなくてもいいのではないか、というのがKの言い分・・・結局目的を前提にしていたという点で、当初のマイクロカーネルの観点でのみ通用する定義でしかなったのだと思う）
• shさん：
  • カーネルが提供するメッセージング機構上に水平にすべてのサービスが配置される
    • （それはあいまいで主観的になるのではないか、というのが誤った見解に基づくKの言い分・・・結局あいまいで主観的なものらしい。それを最初に指摘したときに、それは一面的だというshさんの発言でKは大いに混乱してしまった・・・ご迷惑をおかけしました）
• もなかさん：
  • 教科書的にはshさんの意見は妥当と思う。けれどもこのWikiの主な興味はPC中心のデスクトップOS開発っぽいので、議論の中心が、デスクトップOSにおけるポリシーをどうすべきか、という点に絞られていても無問題と思っている。辞書作るんじゃないんだし。(以上、もなか?が勝手に修正)
    • （おっしゃるとおりです。でもやっぱりそれならそれで、Kは「デスクトップOSにおけるポリシーをどうすべきか」という論点のセクションを作って論議すべきだろうと反省しています。何にしてもマイクロカーネルの定義とポリシーを分離しなかったのはKの落ち度です、というのがKの言い分）
• Gakuさん：(Gakuが大幅に追記)
  • カーネルが提供するメッセージング機構上に水平にすべてのサービスが配置される ( sh さんの言葉を引用 )
  • サービスとはある機能を実現するモジュールのこと。
  • メッセージングとはモジュール間の通信機構のことで、関数コール、共有メモリへのデータの書き込み、イベントドリブンな方式、とどんな通信機構でも良い。
  • 水平とはモジュールが他のモジュールに依存する数が少ないことを言う。
    • 注：水平があるからには垂直があって、垂直とはモジュール間の依存が多いことを言う。モジュール間の依存が多いとは、あるモジュールからのメッセージが目的を達成するまでに経由するモジュールが多いことを言う。理想の水平では、モジュールはカーネルにしか依存しない。
  • カーネルとはそのＯＳで取り替えの利かない部分である。（取替えできると言うことがどの範囲のことを指すかはまだ不明確）
  • カーネルは小さい。小さいとはカーネルが提供する機能の種類が少ないことである。（たぶん、理想的には、メッセージングの機構しか提供しない。）
    • 注：マイクロカーネル度というものがあるとすれば、モジュール間の依存が少ない＝モジュールの配置がより水平に近いものがマイクロカーネル度が高い。モジュール同士が依存せず、カーネルだけに依存する場合が理想のマイクロカーネルである。
  • 以下、大幅な間違いを含む以前の見解 ( Kさんが記述したもの )
    • サーバークライアントモデルでOSのサービスを記述することが、マイクロカーネルの定義ではなかろうか。それぞれのOSのサービスはプロセスの形で記述されることが求められるだろう。根拠は歴史的背景への配慮。分散からマイクロカーネルに進化したとみる。このような構成の理由は、安全の提供である。
    • （安全の提供という面ではKの間違っていた頃と一致した見解で、大いに同意できました。当時のKとの違いは、カーネル－サービス間のみならず、サービス－サービス間についても保護の提供を約束することと、サービスの提供形態はプロセスに限定することです。LCさんの見解に近いと思われます。ということでKの言い分もLCさんへのものと同じです）
• 名無しさん：
  • カーネルが小さければマイクロカーネルで、それはOS作者がここはカーネル、ここはカーネルじゃない、と主張できるくらいに分離されているのであれば充分。サービスがカーネルモードで走っても、もちろんOK。
    • （「マイクロカーネル」ということの意味はその程度なのだろうか、というのが過去のKの言い分。・・・結局、根拠は全然違いましたが、その結論としては、名無しさんは正解を掴んでいた気がします）

参考になる? †

• http://www.ertl.jp/SWEST/SWEST3/e3.txt

サービスがカーネルモードで走ってもマイクロカーネルだと思う人たち †

microkernel/log0

安全かスピードか †

• "開発する時に自制が難しいし楽だから"っていうのはマイクロカーネルの肝だと思いますよ。車でいうとATやABSみたいなもので。ちょっとくらいロスがあっても安全方向に倒すというのが、マイクロカーネルを目指すひとつの理由ではないかしら。スピード命ならMTでエアバックもついていない車に乗ればいいわけで。こういう人たちに相当する指向ならモノリシックで作ればいいでしょうね。 -- もなか? 2003-11-04 (火) 12:09:55
• 車に"スポーツモードABS"なるものが付いているのと同様に、マイクロカーネルにも数々の高速化技法はあるわけですが、使える保護機構を解除してまで高速化する意味はあるのでしょうかね。ABSの制動能力を上げるために、タイヤが横滑りしても構わないって言っているようなものではないかと。 -- もなか? 2003-11-04 (火) 12:22:18

(ここで、shさんから"機構とポリシーは別に考えないと"という説明がありました。内容は、上に移動しています。)

• あ、えーっと。教科書にある"機構とポリシーの話"は了解です(っていうか、すでにshさんが指摘しているので、前提認識と思い込んでいました)。ここで話題を分けたのは、危険側に倒すのはどうして? というヨタな興味だったのですが…。 -- もなか? 2003-11-04 (火) 15:37:43
• つまりshさん的には、上記で「肝」とされた件がマイクロカーネルではそれほど重要ではない、ということなんだと思います。マイクロカーネルでは他にもっと大事なものがあるんだと（僕にはそれは大事そうには見えませんでしたが、まあそれは価値観の相違なのかもしれない）。この「肝」の部分はマイクロカーネルではオプションなのであって、オフにしうるものなんだと。 -- K 2003-11-04 (火) 17:07:39
• 僕はまさにそのユーザモードで活用できる「数々の高速化技法」（まあつまりカーネルモードでも使えるわけですが）が色々出てきて、効率の低下はこんなに少ないよ、マイクロカーネルOSもこうやって作るとうまくいくよ的な話題が来て、OS開発者にとって非常に有益な議論になると期待していたのですが・・・。 -- K 2003-11-04 (火) 17:12:33
• 私は、実行してみないとわからないようなシステムが安全だとは思えないんですよね。ハードウエアでの保護というのはその点でのみ（実用的なパフォーマンスにするために）必要なのではないでしょうか？プロトコルが固定されているようなOSであれば、形式的なチェックで逸脱等の検出が事前に可能なのではないでしょうか？ -- 2003-11-04 (火) 19:11:48
• 不可能ですよ。・・・名無しさんは実はプログラミングの常識を全然知らない人？（いや、いくらなんでもあんまりな意見が続いているので・・・）。もなかさんの2003-11-04 (火) 11:29:39以降の3つの書き込みは読みましたか？分かりやすい具体例だと思うんですが。 -- K 2003-11-04 (火) 20:31:48
• いや、その延長上で話をしているつもりなんで、そう一概に否定されるとあんまり言う気がしなくなってしまうのですが、とりあえず怪しいものは実行させるなってことすら、今のOSの手に負えない仕事ということなんでしょうか？ -- 2003-11-04 (火) 21:59:00
• じゃあ逆にお聞きしますが、名無しさんはどうやって怪しいか怪しくないか判断するのですか。そしてもしその判断が間違っていてカーネルが飛んでクラッシュしたら、その損害賠償をしていただけるのですか？ユーザモード不要論をおっしゃるなら、この質問に「はい」とお答えください。はいと言えないのなら、ユーザモードを使わないと安全は確保できないという常識に、思い込みだけの理由で言い掛かりをつけるのはやめてください。 -- K 2003-11-04 (火) 22:15:44
• ええと、それなら判断出来ない場合はとりあえず全て怪しいということにしてしまいます、とりあえず。その中から、コードをサーチしてみて大丈夫と思えるものだけ、例えばサービスの呼び出し以外していなくて、その呼び出しがプロトコル通りなもの。を安全だと判断します。 -- 2003-11-04 (火) 23:56:09
• 人間の判断は絶対確実にはほど遠いです。1億回テストしても、全ての条件を試したことにならないことはよくあることです。ということで、判断できないものは全て怪しいという見解は極めて納得の行く見解ですが、その中から大丈夫と思えるものを探すなら、たぶん1つも見付からないでしょう。・・・もしこの見極めがOSのサービスレベルのコードでもできると思うなら、そしてそれがほんとにあっていれば、それだけで天才だと思いますし、すぐにビルゲイツを越えるお金持ちになれることでしょう。 -- K 2003-11-05 (水) 00:23:31
• 規定の条件で呼び出していても、カーネル他がプロトコル通りの応答を保証できないという事ですか？いや、それは呼び出したユーザープログラム側が怪しいという問題ではないし、そんなことまでいってたら普通のモノリシックなOSすら作れないと思いますが？ -- 2003-11-05 (水) 01:02:01
• そのとおりであります。「普通の」モノリシックは作れると思いますが、非常に安定したモノリシックカーネルOSはむりでしょう（できないことはないが極端に長い時間がかかる）。大きな額の損害賠償とかが絡むほどなら、僕はマイクロカーネルにします。それで何年も様子を見て、問題は根絶した気がしてきたら、いざというときの損害賠償のための積み立てをやりつつ、カーネルモードへ一つずつ移行させていくと思います。まあ、何年もユーザモードで耐えられたんだから、そこでカーネルモードにして速くする必要があるのかどうかは分かりませんが。・・・安全がスピードよりも大事というのはそういうことです。とにかく自分にはそんなことが保証できるとちょっとでも思っているなら、白痴か英雄ですから、まあ僕のような凡人に理解を求めるのはあきらめてください。 -- K 2003-11-05 (水) 02:08:21
• えと、あの、その、変な定義を増やさないという意味では、shさんのいうマイクロカーネルが一番教科書的というか議論する上での汎用性が高いです。 -- もなか? 2003-11-05 (水) 09:33:00
• しかし、このページでの11/4までのshさんの立場では、"安全かスピードか"という議論はできないです。現在的なマイクロカーネルは、このバランスを"ポリシーの問題"として、放棄してしまいましたから。それはそれで洗練されている考え方ですが、(マイクロカーネルとサービスを含む)OSの開発者からみると、"なにもしてくれない"的な印象を受けるかもしれません。K氏とshさんの意見のずれって、この辺りが根底にあるのではないかしら。 -- もなか? 2003-11-05 (水) 09:44:28
• あと、リングレベルがどうなっているのかというのは、リソース保護に関するOS全体の課題から見れば、些細なことという意見もあるかもしれんです。上で例示しておいてナンなのですが、バッファオーバランのようなエラーよりも、リソースの競合のほうが起きやすく深刻だったりします。ハードウェアリソースならリングレベルで大抵解決できそうですが、カーネルが提供する同期手段(メールボックスとか)の競合は一筋縄ではいきません。些細、っていうのは言いすぎかな。でも、全部ではない、とは言えるかも。 -- もなか? 2003-11-05 (水) 17:05:45
• マイクロカーネルにします：動作が全く保証できないということであれば、それは矛盾していると思います、だって、マイクロカーネルにも、保護機構が使えないマイクロカーネル部分は必要なのですから、この部分は一体どうすればいいんでしょうか？てっきり、部分的に保証できることもあるが、規模が大きくなると保証しきれない部分がでてくるから、全体として保証することは無理になるのではないか？ということで、マイクロカーネルは規模をそうしなくて済む、つまり個々のタスクの規模を（あらゆる入力パターンのテストも可能な程度とかに）押さえれば保証しやすいんだ（保証出来ない部分はたとえばハードウエアの保護に任せとけば少なくてもエラーがでるということは保証できる）＝マイクロカーネルのほうが安全に作りやすいと考える人が多い。という話だとばかり思っていました。ようするにエアバック（保護機構）なんていうのはあくまで非常措置で、真の安全は皆が交通ルール（プロトコル）を守る事で生まれるような感じの。それにしても、怪しいユーザプログラム等であればともかく、まさか開発中ではない完成段階のOSのサービスが、正常終了はおろかプロトコル通りのエラーを返す事を部分的にすら保証できないおっかない代物とは普通思わないのではないでしょうか（確かに売り物ですら未保証、未完成なのは多い訳ですが）、補助輪を外した自転車には乗りたいけどブレーキが効かないのは嫌だなあ。まあ、天才だけの神業であろうが、凡人には極端に長い時間が掛かろうが、とにかく「できないことはない」ということでご理解頂けたのでしたら、「不可能」というのは取り消して、「ただやみくもになんくせをつけているだけ」扱いを反省して頂けると・・・できれば。 -- 2003-11-05 (水) 19:54:07
• "マイクロカーネルは規模をそうしなくて済む"って…マイクロカーネルをちょっとでも調べた人ならL4linuxは知っていますよね…サービスの粒度について、マイクロカーネルは何も関与しないってことまでは、前提知識ですよね? ね? -- もなか? 2003-11-05 (水) 23:26:58
• shさんや名無しさんは保護は要らん(もしくはマイクロカーネルは関与せん)と言っているわけですが、それなりに評価され研究材料でバシバシ使われているL4には、スレッドやメモリのプリミティブな部分を機能の柱として提供しているのですよねぇ。 -- もなか? 2003-11-05 (水) 23:39:51
• 全てのマイクロカーネルを網羅できるくらい勉強したことはないのですが、私が知る限りで、メモリ保護機構を完全に放棄した実装って、ないです。(あったら教えて下さい。) -- もなか? 2003-11-05 (水) 23:54:31
• おまえどっちの味方なんだと怒られそうですが。;) -- もなか? 2003-11-05 (水) 23:55:06
• 仮にマイクロカーネルを、モジュール間にIPCを多用する実装と定義した時、カーネルは最低限、安全にIPCを遂行させたいわけですね。IPCに関するリソース(共有メモリかもしれないですし特定のデバイスかもしれないです)は保護したくなるでしょう。この文脈だと、K氏のいうメモリ保護必要論を支持するわけでもなく、名無しさんのメモリ保護不要論を支持するわけでもなく、でも(IPC保護を目的とする)メモリ保護機構はあったほうがいいよね、という話はありえます。 -- もなか? 2003-11-06 (木) 00:12:20
• また、(1CPU当たりの実行コンテキストが1つなら要らないのですが)効率の為にスレッドが欲しいとなれば、IPCの破れをなくす為に仮想アドレス空間に置きたいなぁ、という話もありえます。 -- もなか? 2003-11-06 (木) 00:30:39
• あ、仮想アドレス空間でなくてもいいか。筆が滑りすぎました。実現方法はともかく、保護したいという話はありえます。 -- もなか? 2003-11-06 (木) 00:33:25
• "おっかない代物とは普通思わない"はずのところからバグはでるわけでして。交通ルールを守っていても、車は故障し暴走するわけですよ。ABSだって、日常的に作動するほど踏んでいる奴は相当ド下手な奴でして。そういうのは論外。しかし上手いから熟練しているからABSは要らないという話には必ずしも繋がらないですよね。 -- もなか? 2003-11-06 (木) 00:40:14
• あ、すいません、「規模をそうしなくても済む」って意味で、勿論「そうしなければ」という意味ではありませんし、そう主張したいわけでもありません。対立軸の話でなければ別にマイクロカーネルでなくてもいいわけですし、そういう細切れでも（別の見方から）モノリシックと言えるという話も否定しません（K氏には混沌だと怒られそうですが）。で、興味があるのは安全のための最小条件はなんだろう？って話ですね。例えば交差に信号というのは必要なのか？いやインターチェンジにすればいいんだとかそれじゃコストかかるだとか。 -- 2003-11-06 (木) 01:29:43
• 何を守りたいかってことが明確に定義されていなければ、最小条件も定義できませんね。IPCを守りたいのか、もっと手広くサービスを守りたいのか、ユーザランドまで守りたいのか。物的/論理資源を守りたいのか、はたまた時間資源を守りたいのか。 -- もなか? 2003-11-06 (木) 10:29:51
• 現在的マイクロカーネル原理主義に則りIPCだけ守りたい、という前提であれば、論文読み漁れば答えはみつかるのではないかなぁ。その答えがデスクトップOSの作者たちにとって有用かどうかはまた別の話ですが。 -- もなか? 2003-11-06 (木) 10:39:35
• 「バッファオーバランのようなエラーよりも、リソースの競合のほうが起きやすく深刻だったりします。」：まあその点はわからないでもないです。リソース競合を回避できるうまい方法があれば、それを活用した新しい概念が提唱されるのではないでしょうか。とりあえず使える道具として、「ユーザモードの活用を」というのは、僕はおおいに納得できるんですが・・・。 -- K 2003-11-06 (木) 14:52:41
• 結局、マイクロカーネルOSにおいて、サービスをカーネルモードで走らせることで速度の問題を解決する、というのは、CPUのオーバークロックみたいな解決方法だと思います。OS開発者ではなく、OS運用者がリスクを背負い込んで進む道です。それは有力な解決法の一つですし、そういう選択肢が与えられているのはすばらしいことですが（それがポリシーの分離ということなんだと思う）、しかしそれをもって「マイクロカーネルの問題が一つ解決した」というのは違うと思います。 -- K 2003-11-06 (木) 15:49:07
• マイクロカーネルではなくマイクロカーネルOSと書いたことに意図はありますか? -- もなか? 2003-11-06 (木) 16:36:32
• この辺りに立場のずれの本質があるように思うのですよ。マイクロカーネルそのものは、ろくにアプリケーションの保護をしてくれない存在ですよ。ゆえに「パーソナリティ」などと呼ばれる、ポリシーを実現するソフトウェアが要るわけですよね。K氏はマイクロカーネルに過大な期待をしているか、パーソナリティを含んだものを扱おうとしているかのどちらかに(私は)見えます。 -- もなか? 2003-11-06 (木) 16:42:12
• 意図はあります。マイクロカーネルだとカーネルしか指さない場合もあるというのが今の見解なので、マイクロカーネルを採用したOSという意味で、「マイクロカーネルOS」と書きました。それ以上の意図はありません。 -- K 2003-11-06 (木) 16:43:57
• マイクロカーネルOSという表現から、マイクロカーネルを採用した(パーソナリティを含む)OSという意図があるのかなぁ、と思えたもので。 -- もなか? 2003-11-06 (木) 16:49:16
• ええと、僕はマイクロカーネルは、カーネルだけをサービスやアプリのバグから守ってくれるものと思っています。もちろんサービス同士でバグによる干渉が起きないように、タスク機能を提供してくれているんだといえばそのとおりですが、サービスをどう書くかはOSを作るときに（カーネル以外のサービスを作るときに）、実装者、もしくはディストリビュータが選択することだと思います（いくつのプロセスに分けるか、とか）。ただそれでも、ユーザモードで走るように書くというのは（マイクロカーネルである以上の）共有のルールだと考えているわけです。 -- K 2003-11-06 (木) 16:49:55
• (入れ違った…) なるほど。 -- もなか? 2003-11-06 (木) 16:50:21
• 安全性の確保というのは、マイクロカーネルの目的というよりは、OS共通の目的の一つであって、安全とわかっているOSの機能を増やしてより安全にしようというのがモノリシック的考えの一つにあったんじゃないでしょうか？ただ、色々やってるうちにOS自身が本当に安全かどうなのかわからなくなってしまったところに逆転の発想が生まれたのではないかというのが私の想像です。つまり安全を犠牲にしない範囲で色々削ぎ落したらどうなるかと極限までやってみたら、小さなカーネルだけが残って、これをマイクロカーネルと呼んだんじゃないでしょうか？そうして機能を減らしてもシステムの安全性は確保出来るって話になって、その議論の過程でマイクロカーネルは、システムの作り様によっては（モノリシックよりも）安全だという話がでてきただけで、マイクロカーネル自体が必ずしも安全性向上の目的でつくられたわけではないと思います。つまりマイクロカーネルと言うためにはモノリシック並の安全性が確保出来れば充分で、それ以上はオプションの話だと思うので、過剰な必須条件の設定には反対だというわけです。で、どうもモノリシックと同じ外的条件では成立しないというハードウエア依存の定義というのが引っ掛かるんですよね。それじゃ「どこでも」って事にならないんじゃないかと。 -- 2003-11-06 (木) 20:21:33
• おもしろい！＞前半　　確かに安全の追求はOS共通の目的とはいえそうです。しかもモノリシックはボトムアップ式という観点は、なるほどこの説明では一つの観点として成立している気がします。・・・でも「つまり安全を犠牲にしない範囲で」の一言はよくわかりません。そこを飛ばして読めばとりあえず分かります。 -- K 2003-11-06 (木) 20:33:28
• 一番最後の、「どこでも」っていうのはもなかさんの発言をうけてのことだとおもいますが、そのどこでもは、分散のことを言われていたんじゃないかと僕は思います。あるOSサービスが、ネットワークの向こうで走っていてもよい、みたいな。どのハードウェアでも動くみたいな、意味合いじゃなくて（それはそれで移植性の問題かと）。・・・それで本題ですが、つまり名無しさんの定義としては、カーネルが小さければマイクロカーネルで、それはOS作者がここはカーネル、ここはカーネルじゃない、と主張すればOKというわけですね？（似たようなお話はかつて伺いましたが、これを名無しさんの今の見解としていいわけですね？）。僕の主張としては、そんな主観で左右されるような定義なのか？それでいいのか？なのですが、名無しさんとしては、もちろんそれでいい、問題無い、と。 -- K 2003-11-06 (木) 20:42:28
• これでOKということでしたら、喜んで上の名無しさんの見解を修正させていただきます（もしこれだったら：なんだそうだったのか、これが名無しさんの意見だったのかー。苦し紛れの言い訳だと思っていました。誤解をお詫びします）。 -- K 2003-11-06 (木) 20:45:59
• この欄で続けていいのかよく分かりませんが、要するにカーネルというのがなんなのか、何故（いくら小さくしようと思っても）必要かということですね。そんな作者がこれはカーネルじゃないと言っただけでカーネルじゃ無くなるようなものじゃないと思うんです。それならそもそもそのサービスはカーネルとは言えないものではないかと？ただし、一体化している他の部分がカーネルであれば、モノリシックな全体としてカーネルなので、その部分もカーネルの一部とは言えるんじゃないでしょうか？ -- 2003-11-06 (木) 21:14:17
• うーん、だめだ。名無しさんのその話は全く分からない・・・。まず、この見解はやっぱり名無しさんの見解ではないということでいいですか。はいとかいいえとかで答えてもらえないと分からないので・・・。カーネルが何なのか分からないということに関しては、申し訳ありませんが僕にはあまりに面倒なので、適当に調べて勉強してきてください。・・・しかし何を持ってカーネルとするかという議論は、実は個人的には興味はあります。というのはOSASKはカーネルレスなどと言っているからです（笑）。・・・じゃあ、Kernelというページを作るのは、OS-Wiki的にはありなんだなあ。名無しさんはそういうページがあったほうがいいですか？ -- K 2003-11-06 (木) 22:26:04
• つまり、カーネルが小さければマイクロカーネルで、それはOS作者がここはカーネル、ここはカーネルじゃない、と主張できるくらいに分離されているのであれば充分だということです。そこでカーネルじゃないとされた部分が本当はカーネルだと言えるというならそれは分離できていない（モノリシック）という主張ではないでしょうか？ -- 2003-11-06 (木) 22:42:11
• 了解です。その路線で名無しさんの見解のところを今日中に書き換えたいと思います。細かいことを確認しますが、その目的は安全ではないんですよね？それとも安全？ -- K 2003-11-06 (木) 22:58:00
• 安全を全く考えなければ独自にやらせればいいわけで、マイクロとはいえカーネルが残った意味はなんだろうって思ったので、犠牲にしない範囲でと書いた（例えば補助輪は外すけどブレーキは外さないみたいな）訳ですが、それが別の理由であれば関係ないと思います。但し、派生した中に安全を目的としたものはあると思うので、そうでなければマイクロカーネルとは言わないとかいう話でなければ、それらを否定する気はないです。 -- 2003-11-07 (金) 00:27:33
• 「どこでも」は、分散かもしれませんし、同一CPUの内かもしれません、という意味です。 -- もなか? 2003-11-07 (金) 08:52:52
• 大事なのは実行コンテキストであって、物理的位置ではない…はず。だから現在的マイクロカーネルにもスレッドサポートがある…のでは? 思考実験では、面倒なので、物理的実体としてのCPUを例示しちゃいますけれど。(それが混乱を招いたとしたら申し訳ない) -- もなか? 2003-11-07 (金) 09:12:00

こめんと欄 †

• 上記の指摘のように徹底したマイクロカーネルは、頻繁なカーネルモード←→ユーザモードの切り替えが起きて、効率が落ちるのは確実である。しかし、これは最近の高速なCPUにあっては誤差範囲の負荷で収まるのかもしれない。その辺はまだ僕には何ともいえない。 -- K 2003-10-12 (日) 21:06:01
• マイクロカーネルを目指しているMonaのひげぽん?と申します。もし以下の私のコメントが議論の流れから外れていたり、意味がわからない場合は無視していただきますようお願いいたします。
• マイクロカーネルがOSの機能をカーネル本体から外にサービスとして追い出して提供していた場合(それがカーネルモード・ユーザーモードに関わらず)、マイクロカーネルと呼ばれるOSたちは以下のどのレベルでサービスを提供をしているのでしょうか?もしくは期待されているのでしょうか?
  1. I/Oアクセスをダイレクトに行うサービス
  2. ディスクを操作するサービス
  3. ファイルシステムを操作するサービス
  4. 仮想ファイルシステムを操作するサービス
• これから徐々にマイクロカーネル化を進めるにあたっての疑問点を書かせていただきました。-- ひげぽん? 2003-11-03 (月) 00:51:00
• せっかくなので、今からちょっと整理します。みなさん、10分ほどお待ちください。 -- K 2003-11-03 (月) 00:56:52
• 整理できました。 -- K 2003-11-03 (月) 01:13:44
• ええと、「理想的な」マイクロカーネルとしては、カーネルは「カーネルにしかできないことだけをやる」ということになっています。つまり、一般的に言うと、I/O命令とコンテキストスイッチくらいでしょうか。そうなると、ディスクの操作とかはユーザレベルのサービスで、カーネルの外におかれ、この実際のアクセスのときに、カーネルにI/O命令を実行してもらうわけです（カーネルは、inp(adr);とout(adr,dat);のみのサービスがある、とか）。・・・しかしこれはあくまでも理想論であって、これをまじめにやるとあまりにしんどいので、実際はこれに加えてもうちょっと膨らみを持たせる場合がほとんどだろうと思います。 -- K 2003-11-03 (月) 01:17:13
• 実際のOSの例を紹介できると非常に参考になると思いますが、僕はマイクロカーネルOSの実例にはあまり興味がないので詳しく知りません。きっとそれは詳しい方がここに書き込んでくださるだろうと思うので、しばらく待ってみてください。 -- K 2003-11-03 (月) 01:23:15
• 一つ見つけました。B-Freeの例です。http://www.tron-net.gr.jp/~takada/B-Free/misc/bc/2/ ページの中頃に「全体構成」という部分があり、ここを見ると分かりやすそうです。デバイスドライバがマイクロカーネルに少し潜っているところが、理想と現実の差であろうと思います（理想では潜らないで矢印でつなぐべきですが、そういう風にはしないでドライバの一部はカーネルモードで走るようにしたのでしょう。妥当な判断だと僕も思います）。こういう図をもっと捜せたら、きっとひげぽんさんの参考になりそうですね。 -- K 2003-11-03 (月) 01:29:04
• その図の中のLOWLIBについては、http://www.tron-net.gr.jp/~takada/B-Free.old/mail-archive/oldmail/0511.html という意見があるようです。 -- K 2003-11-03 (月) 01:34:51
• Kさん、丁寧な解説ありがとうございます。osdev-jのなかにはI/Oアクセスタスクと作るというご意見もありました。理想と現実も考えどころだと感じました。 -- ひげぽん? 2003-11-03 (月) 01:37:15
• NTはそんなことやっているのかDLLで。大変参考になりました。 -- ひげぽん? 2003-11-03 (月) 01:39:01

• 以下は、LC氏の定義と僕の定義との差についての考察です。：
  • LC氏の定義：サービスはユーザモードで走ることではなく、プロセス（タスク）の形で分離されていなければならない。
    • 参考：http://pc.2ch.net/test/read.cgi/os/1065940450/
  • K：プロセスとして分離されていなくても、ユーザモードであればよい。 -- K 2003-11-03 (月) 11:09:16
• 僕の理解が正しければ、たぶんLC氏の定義こそもっとも純粋な形での定義です。そもそもユーザモードでサービスを走らせる形態が採用された理由は「安全・開発の負担の軽減」ということであり、それならプロセスとして独立して書けるほうが圧倒的にこの点で有利であろう思われるからです。ということで、1年くらい前までは僕もLC氏と同じ考えでした。 -- K 2003-11-03 (月) 11:12:59
• しかしマイクロカーネルにおける現実問題を直視すると、みんな「安全・開発の負担の軽減」を多少犠牲にしても、実行速度の遅さの解消の方向へ踏み出しているようにみえます。ということで、この定義を少しゆるめたほうが現実的ではないかと思いました。またたくさんの方に「その定義はきつすぎる」と教えていただきました。それで現実的な定義を教えていただいた結果が、このユーザモードで走らせる、ということだったのです。LC氏の定義にあっても、もちろんサービスはユーザモードでのみ走ります（アプリがカーネルモードで走るなんてことは非常識なわけで）。ですから、LC氏における定義のマイクロカーネルOSは、そのまま僕の定義のマイクロカーネルOSとしても受け入れられるものです。僕のほうが扱える範囲が広いので、逆は真ならずですが。 -- K 2003-11-03 (月) 11:21:14
• プロセスとして分離しないサービスの場合、メモリ空間を切り替えないで済むために（IA-32でいえばCR3の変更を回避できる）、さらにタスクスイッチも回避できるので（環境の切り替えのコストを回避できる）、明らかに軽くはなります。その代わり、同じ空間で走っている他のアプリやサービスが互いに過剰に影響しあうことがありえます（つまり、アプリのバグがサービスを破壊しうるなど -- 逆もありえます）。また、そういう可能性が排除できなくなると、開発の負担も多少増えるでしょう。・・・しかしこれを導入しないで同じ速さを手に入れようと思えば、気が狂うほどのチューニングをやったり、何割か速いハードウェアが必要になるでしょう。どちらのコストが問題なのかという判断を、OS開発者が選ぶわけです。 -- K 2003-11-03 (月) 11:31:47
• しかし、たとえばsegmentationを活用したりすれば、アプリがポインタを間違っても同じ空間内にあるユーザモードサービスを破壊しないで済むようになります（もちろん全てのケースを防げるわけではありませんが、9割以上は防げます）。それ以上を望むならLDTRをサービスとアプリとで分ければ（そしてGDT内にはカーネルモードでアクセスできるセレクタしか置かなければ。ただし、当然ながらLDTRの変更の際にカーネルモード←→ユーザモードの切り替えが必要になりますが）、分離はほぼ完ぺきなレベルにまで達します。 -- K 2003-11-03 (月) 12:26:51
• LC氏としては、たぶんセグメンテーションを活用するという選択肢を最初に除外してしまっているために、必然的にページ空間の切り替えが必要になり、そうなるとプロセスとして分離せざるを得ないということになっている面もあるのではないかと、僕は考えています。LDTRを切り替えてしまえば、OSが提供するセグメントセレクタの構成を一変できるため、同じページ空間であってもお互いに干渉できなくすることが可能なわけです。 -- K 2003-11-03 (月) 12:31:29
• 僕もLC氏も、「メモリ空間の分離のために」という共通の目的を想定していることに留意してください。また僕の定義の一番緩い解釈である、「セグメンテーションも使わないで、全部のサービスとアプリが同じ空間にある」といった場合でも、ユーザモードでのバグはユーザモード内の他のアプリやサービスを破壊することがやっとであって、カーネルは無傷です。そして、カーネル自身も最小限に小さくしてあるので、カーネル自身のバグ残存率も多分期待しうる最小値にまで下がっているでしょう。・・・僕の今の考えではユーザモード内の各モジュールの独立性を高めることは、マイクロカーネルそのものよりも、モジュール化や分散や仮想化の考え方に負うところが大きいと思います。そしてその実現としてはメモリ空間の分離が必要になるでしょう。そうなると、セグメンテーションやプロセスによる分割が必要になると思います。 -- K 2003-11-03 (月) 12:45:35
• つまり僕の考えにおけるマイクロカーネルという語の意味は、純粋にカーネルがそれ以外からの干渉で傷つかない保証と、カーネル自身が最小構成でバグフリーあることの2つだけに限定していて、カーネルから追い出されたサービス群が超巨大で統合された単一のモジュールで提供されていようが、きれいにモジュール化されていようが、それは問わない、としているわけです。実際のマイクロカーネルOSは、ほとんどすべてのケースで、きれいにモジュール化されているでしょう。しかしそれはマイクロカーネル＋モジュールと考えるほうが合理的で分かりやすいと思うわけです。実際マイクロカーネルOSにおける個々のサービスの分割の度合いはOSによってまちまちです（さすがに超巨大1個というのは滅多にないと思いますが、ここまできれいに分けたかと思えるほど分割したものがあるかと思えば、ファイルシステム、GUI、などという大きな区分止まりのものもあります）。・・・そう考えると、カーネルとそれ以外のメモリ空間の完全分離は絶対に譲れないラインですが（だからサービスはユーザモード以外にありえない）、ユーザモード間の分離には選択の余地を残していいのではないでしょうか（つまりプロセスによる分離にこだわらなくてもいいのではないか）。そう考えるかどうかが僕の定義とLC氏の定義の違いだと、僕は思っています。 -- K 2003-11-03 (月) 13:04:34
• こんにちは。書き込んでも良いのかな？ -- Gaku? 2003-11-03 (月) 21:45:48
• どうぞー。 -- K 2003-11-03 (月) 21:48:54
• 自分は↑のKさんの意見とは異なり、マイクロカーネルと言うのは、OSの機能を出来うる限りタスクに逃がしたものだ。と考えています。 -- Gaku? 2003-11-03 (月) 21:53:25
• （注１：↑でKさんがLCさんの意見では。と称しているものと同じかと思います。） -- Gaku? 2003-11-03 (月) 21:53:49
• （注２：タスクという語は色んな意味に使われるので、非常にあいまいなのですが、自身の外とは隔絶して命令の塊を実行できるような、資源を持ったまとまりのことだと考えています。） -- Gaku? 2003-11-03 (月) 21:54:09
• （注３：タスクという語が以前あいまいなのですが↑で、もなかさんが例に出していた１ＣＰＵ１サービスというイメージがぴったりであろうと考えます。実際に即して言えば、プログラムカウンタが（タスクから）出たり入ったりしない。という感じでしょうか） -- Gaku? 2003-11-03 (月) 21:55:33
• なぜ、そう思うかについてもう少し根拠を述べた方が良いか少し迷いますが、この話は脇におきます。 -- Gaku? 2003-11-03 (月) 21:56:59
• 書籍を読んだ後のＫさんも、タスクにサービスを出来る限り持って行く。という理解だった、ということは多分、書籍の解説はタスクに処理をなるべく持っていく。という記述だったのではないかと思います。（少なくても自分の現状の理解ではそうなっています） -- Gaku? 2003-11-03 (月) 22:00:20
• とすると、なぜ、ある程度（世間？）の了解を得ていると考えられる書籍の定義とは別の定義を持って、全く同じマイクロカーネルという語の定義に当てるのか。ちょいと興味を覚えました。というだけの書き込みにしては長かったですね。 -- Gaku? 2003-11-03 (月) 22:02:55
• ええと、レスを期待なさっているのか、それともただ興味がありましたという表明なのか分からないのですが、まあとりあえずレスを書きます。・・・って11/03-11:21のところにある通りです。個人的に決定的だったのは、#osdev-jで僕以外の全ての方が、「プロセスやタスクの形でカーネルから追い出さなければいけないとは限らない」とおっしゃったことで、その後自分でもよく考えて、なるほどそう考えるほうが分かりやすいし本質的だろうと思ったからです（カーネルを守ることが主な意図であって、プロセスにするか、スレッドにするか、それともサブルーチンか、はマイクロカーネルの本質ではなくてモジュール化のレベルとして論じるほうがいいのではなかろうかと）。 -- K 2003-11-03 (月) 22:38:58
• ついでに補足しておくと、なんというかタスクが何かというのも結構あいまいかなあと思ったのです。Gakuさんのここでの一時的な定義だと「自身の外とは隔絶して」とあるので、スレッド方式は駄目ってことになるでしょうか？それともプロセス内全体を「自身の中」と見なしうるからOK？・・・また僕は、APIの解釈などもOSの基本的なサービスと考えるのですが、そうなるとWindowsにおけるKERNEL32.DLLとかも本来はタスクにするべきなのかという困惑もあります。理想的にはタスクにするべきなのかなあ。それはあまりにも酷な気がするのです。この辺はどう思われますか？（これはまさに上記のB-FreeのLOWLIB問題なのかもしれませんが）。 -- K 2003-11-03 (月) 22:58:59
• なるほど。了解です。レスありがとうございます。 -- Gaku? 2003-11-03 (月) 23:42:31
• うわ。入れ違った。議論したら面白そうかなぁと思いつつ、時間かかりそうだなぁと思っている段階ですが。 -- Gaku? 2003-11-03 (月) 23:44:08
• （独り言です）読んだ感じでは、サーバ・クライアント型のＯＳである＝マイクロカーネル方式である。と言えるか。ということかな。議論の成り行きを待ってみよう。Ｋさんはサーバ・クライアント型＝マイクロカーネルで納得するかな？ -- Gaku? 2003-11-04 (火) 20:20:38
• 質問です。ここでいうサーバクライアント型っていうのは、UNIXでいうところのデーモンプロセスみたいに、ずっと居座るような方法でサービスを提供する、ってことですか？（たぶんGakuさんが言いたいのはこっちのことだと思う）・・・それとも、単にリクエストを待つ側と、リクエストする側がいるというだけのこと？ -- K 2003-11-04 (火) 22:55:43
• 上を書くに当たって念頭にあったのは前者（ずっと居座るような方式）です。何か気になる点があったのなら教えて頂けるとありがたいです。 -- Gaku? 2003-11-04 (火) 23:33:35
• ちなみに、後者（リクエストを待つ側とリクエストする側が居るだけ）だと考えている場合、関数呼び出しも含んで良い事になりそうです。関数呼び出しでは、どこで（実行）コンテキストが区分されるか判断できないように思えます。判断できないとすると、マイクロカーネルはサービスを（上記注２のように自身の外とは隔絶している）タスクに追い出ようなことだと私は考えているので、サーバ・クライアント型＝マイクロカーネル、という発言は自分では！＝だと考えていることになります。 -- Gaku? 2003-11-04 (火) 23:41:32
• せっかく話し始めたので、ついでに。 -- Gaku? 2003-11-04 (火) 23:55:00
• スレッド方式は駄目ってことになるでしょうか？＞分かりません。勉強不足で恥ずかしいのですが、自分の見解では、スレッドを使った場合、目的は達成できないけれど仕組みは真似できる気がします。仕組みがまね出来ていれば、マイクロカーネルの一種であるとしても良いかもしれません。しかし目的が達成できていないという非常に中途半端な状態になってしまう気がします。 -- Gaku? 2003-11-04 (火) 23:55:38
• APIの解釈などもOSの基本的なサービスと考えるのですが、(中略)、理想的にはタスクにするべきなのかなあ。＞しても良いししなくても良いと考えます。ＡＰＩと言ったときに提供の仕方は、スタティックライブラリ、共有ライブラリ、サービス（システムコールであるとかデーモン的なタスクであるとか）と選択肢が色々あると思います。どれを選択するかは開発者の最良であると思えます。 -- Gaku? 2003-11-05 (水) 00:05:44
• と。一つ重大なミスに気づきました。「マイクロカーネルと言うのは、OSの機能を出来うる限りタスクに逃がしたものだ。」＞「マイクロカーネルと言うのは、従来型のＯＳがカーネルに持つ機能を出来うる限りタスクに逃がしたものだ。」と書き直したほうがより正確に上の書き込みを読めると思います。（書いた時はＯＳ≒カーネルでも大して混乱しなかったと思いますが、上記の文脈では混乱しそうです）ＯＳと言うと、カーネル以外も含む非常に大きな概念になってしまうので。 -- Gaku? 2003-11-05 (水) 00:09:05
• いや。↑も変な気がするな・・やはり最初の表現の方がしっくり来るかな？・・。とりあえず、どこまでをタスクに分離するかは開発者の裁量なのではないか。（カーネル内に残るサービスの種類はなるべく少なくするという制限があるでしょうけれど）と言いたかった訳です。 -- Gaku? 2003-11-05 (水) 00:15:50
• 11/04-23:33の気になる点のこと：　これはまだ自分でもはっきりしていない考えなのですが、一応書いておきます。今のマルチタスクの技術って、もともとは1つのCPUタイムの有効活用のために考案された仕組みだと思うんです。マルチプロセッサ用に書かれたコードをシングルプロセッサでも走るようにするエミュレータ技術、というものではなくて。Gakuさんの見方だと、これをあえてエミュレータとして捉えたのが、まずおもしろいと思いました。・・・それで、タスクの実現方法ですが、今では一般的な時分割方式のほかに、イベントドリブン型や、もっと原始的なコールバック方式などがあります。単に「リソースを持って居座る」というだけだと、必要に応じて呼び出されるようなドライバルーチンみたいなのも含まれるわけです。それらを排除するために、「プログラムカウンタが（タスクから）出たり入ったりしない」という記述をしたのだろうと思っています。 -- K 2003-11-05 (水) 16:22:41
• しかし僕からするとこれはなんとなく些細なプログラミングスタイルの差にも思えるのです。コールバック式がアウトでイベントドリブン式がOKとか、もしくはイベントドリブン式もアウトで、時分割がOKというのはほんの些細なプログラミングスタイルの問題に思えないでしょうか？（まあそれでも、確かに時分割とコールバック型とではサービスの書きやすさがかなり違いますが）。・・・で、僕はここから先に思考がすすまないのですが、それはやっぱり「目的」の問題じゃないかと思います。Gakuさんの定義の場合、マイクロカーネルでOSを設計することは、何を意図しているのでしょうか？サービスの記述を楽にして、OSを書きやすくするため？それとも安全？そしてそのためには、タスクの実現のレベルも規定する必要がある？（イベントドリブンだと、あるタスクがバグで無限ループに入ったら全体が止まっちゃうから、開発の容易さとか、安全を考えるならアウトですね・・・というふうに、目的があると判断が前に進むかと）。 -- K 2003-11-05 (水) 16:32:07
• もしもコールバックタイプもGakuさんの考えるところのタスクの一形態とみなしうるなら、DLLとかだって条件を満たすわけで、APIはタスクじゃなくてもいいけど、ファイルシステムはタスクじゃなきゃ駄目、というやや作為的な分類は撤廃できます（サービスのタイプによってタスクにするべきかどうかが変わるというものなんか気持ち悪いなーと僕は思うわけです）。・・・いや、そうすると僕の定義みたいになってくるから、Gakuさんとしては賛成してもらえなさそうですが。 -- K 2003-11-05 (水) 16:40:47
• まず、私の見解ですが、sh さんともなかさんの言っていることと同じような気がします。しかし、「カーネルが提供するメッセージング機構上に水平にすべてのサービスが配置される」と言ってしまうと何のことだか分かりません。だから自分なりの解釈で話を進めます。ところで、先ほど11/4のもなかさんの車のAT/ABS辺りの話に気づきましたが、以降に書くことはこれと大体同じことだと思います。 -- Gaku? 2003-11-05 (水) 22:12:56
• それで、私がマイクロカーネルというＯＳの構成法を指す語から想像するＯＳ像は、安全性を高めることを目的にしています。（安全性だけではなくて、管理し易いだとか、拡張し易いだとか、もあると思いますが、副次的な効果であるというイメージを持っています） -- Gaku? 2003-11-05 (水) 22:19:45
• 安全性を高める。という目的を実現するために、ＯＳの出来るだけ多くの機能をタスクに持って行く。という方針で構成します。 -- Gaku? 2003-11-05 (水) 22:22:58
• 安全性を確保するためには、まず、開発されたコードが正しい必要があります。人が正しく管理できるコードのサイズはできるだけ小さい方が良いです。だから、きっと幾つかの十分に管理できる大きさに機能を分割します。これは一般的にモジュール化と呼ばれるはずです。（モジュールは自分の中が正しいことに努力します）しかし、安全性の確保にはモジュール化では十分ではありません。モジュールは、自分以外の悪意あるコードもしくは、バグを含んだコードに破壊されるかもしれません。また、モジュールが、関数コールのように実行権利（プログラムカウンタ）を自分の外に渡してしまうとすれば、もう一度、正しく自分のコードに実行権利が戻ってこないかもしれません。 -- Gaku? 2003-11-05 (水) 22:32:43
• これらの障害を乗り越えて安全性を確保するために、適度な大きさの機能に分割したサービスを、それぞれ自身の外とは独立した環境で動作させます。外からは自身のコードには触らせないし、実行権利（プログラムカウンタ）も渡さないし、その他の資源にも触らせない。というのが安全上の理想なのですが、互いに全く独立していると何もできません。仕方がないので通信手段を設けます。この通信手段は安全性を確保することが目的なので、非常に安全に、決められた情報だけ伝達する通信手段です。以上のことは多分、安全性を確保する目的を達成するために、ＯＳの機能を適度に分割して（自身の外とは隔絶した）タスクに持って行く。タスク間は規定された通信手段を設ける。という方針を採ったということです。 -- Gaku? 2003-11-05 (水) 22:40:39
• さて、上記の目的と方針で、１ＣＰＵもしくは、ＯＳの機能を分割したタスク全部を動かすのに十分でない数のＣＰＵを持つマシンで、ＯＳを実装しようとします。きっと複数のタスクが動いている状態を真似する機構が必要です。方針は方針でしかないのでどんな方法で実装しても構いません。 -- Gaku? 2003-11-05 (水) 22:43:42
• 多分、１ＣＰＵなどの状態で、安全性の確保という目的と、タスクで構成するという方針を実現しようとすれば、ＣＰＵの保護機構が必要です。また、ＣＰＵの保護機構を使って、それぞれのタスクに、自身の外と隔絶（したつもりに）させてやる何者か（カーネル）が必要です。 -- Gaku? 2003-11-05 (水) 22:52:10
• ところで、ＣＰＵの保護機構を使うというのは、実装上の選択である。と言えるような気がします。例えばタスクの代わりにスレッドで動いているのはどうか？というような、タスクの機構と規定された通信機構を持っていれば、方針を満たしているのではないか？という訳です。しかし、スレッドで機構を真似しても、安全性という目的を達成できないので、やってることが中途半端な状態だと思われます。 -- Gaku? 2003-11-05 (水) 22:56:46
• 大体こんなところだと思いますが、上記「中途半端な状態」という言葉は視点を変えると非常に不適切な表現です。実際にモノを作るときには多分いくつか（安全性とか高速性だとか）の理想が出てくると思います。その中にはあちらを立てればこちらが立たずというものが多分存在するはずなので、安全性のみ追及した状態というのは他の理想からは全く持ってダメな状態である可能性があります。つまり、上記の「中途半端な状態」というのは、視点を変えると「絶妙なバランス」なのかもしれないです。でも、マイクロカーネルを安全性を目的とした、と定義すれば、この安全性の観点から中途半端な状態にこの名前を使うのはよろしくない気がします。もし使えるならば、安全性を追及した、というのは不正確な表現になってしまいます。といったところでしょうか。 -- Gaku? 2003-11-05 (水) 23:03:35
• 追記。タスクに機能を持って行くのは、カーネルの安全性の確保だけではなくて、タスクに分割されたそれぞれの機能の安全性の確保でもあります。 -- Gaku? 2003-11-05 (水) 23:08:47
• しつもん。何に対して"安全"なのですか? -- もなか? 2003-11-06 (木) 10:44:41
• Gakuさんの説明は僕の観点とは違うんですが、しかし「安全」という目的が提示されて、すごく分かりやすくなりました。ありがとうございます。 -- K 2003-11-06 (木) 14:12:40
• 僕は「マイクロカーネル」というのは主にカーネルの構成法で、カーネルから追い出されたサービスの構成法への言及はあまりない（カーネルを壊さなければそれでいいという程度）だろうという考えがあるのですが、そのへんはGakuさんとしては、サービスAとサービスBが干渉し合わないことも含めようというわけですね。なるほど。 -- K 2003-11-06 (木) 14:15:35
• 「安全」こそマイクロカーネルの本質であって、「開発しやすい」とかはそれに比べれば副次的なこと、というのは非常に的確な指摘に思えます。僕もその意見に賛成です。開発しやすくすることが目的なら、開発時だけユーザモードにすればいいのであって、運用時はカーネルモードでもいいんだもんなあ。バグが残っているかもしれない、残っていても大丈夫、というのが重要だと気づきました。ありがとうございます。 -- K 2003-11-06 (木) 14:57:38
• ｓｈ氏の機構とポリシーを分けてカーネルを設計するという考え方は非常にマイクロカーネルの本質をついた考え方だと思います。前に、もなかさんも提案したように、機構とポリシーの分離に関して話を進めたらどうでしょうか。私も関心があります。 -- zaku? 2003-11-06 (木) 19:34:38
• それは変な気が・・・。機構とポリシーの分離というのは、マイクロカーネルの本質なのですか？そうでなくて、どんなカーネル設計おいても機構とポリシーの分離は取り入れられるのではないですか？ -- K 2003-11-06 (木) 19:48:40
• 自分は組み込みシステムをテーマにしている研究職のものですが、リ○ーでMach関連をやっていたときからすでにポリシーの分離は大きなテーマでした。いま私が扱っているマイクロカーネルはスケジューリングポリシーまでプロセスから与えられるようになっています。 -- zaku? 2003-11-06 (木) 19:55:47
• ありがとうございます。確認したいのですが、もしそれが本質だとすると、機構とポリシーの分離を果たしていないマイクロカーネルは、マイクロカーネルとしてはもはや認めがたい、もしくはマイクロカーネルとしては不純である、ということになるんだと思うんですが、この理解であっていますか？そして、機構とポリシーの分離さえ果たしていれば、他の条件に関わらず、マイクロカーネルと呼んでもおかしくはない、と。 -- K 2003-11-06 (木) 20:01:57
• 機構とポリシーの分離を取り入れた方がよい、という点では、僕も文句なく賛成です。 -- K 2003-11-06 (木) 20:02:39
• サービスがカーネルモードで走るという話は最近の話ではないと思います。MacOSXが登場したときそのような記事を雑誌で読みました。MacOSXにも一部そのような機構が導入されたと記憶しています。その辺に詳しい方がおられたら教えていただけますか。 -- zaku? 2003-11-06 (木) 20:07:38
• 正直なところ私の周囲ではあまりマイクロカーネルとかモノシリックカーネルといった分類では考えていません。ロッキングの粒度とか、実時間性とかを主に扱います。だからKさんの質問にはうまい答えが見つからないのが本当のところです。すいません。 -- zaku? 2003-11-06 (木) 20:10:25
• sh氏の指摘どおり私はマイクロカーネルというのは高いレベルの概念だと思いますので、純、不純はないと思います。 -- zaku? 2003-11-06 (木) 20:13:58
• それぞれは面白い話題ですので、実際にそのへんの技術を扱うOSがprojectsに入ってくれさえすれば、マイクロカーネルとは別にして、ちゃんとやりたいです。＞機構とポリシーの分離、ロッキング粒度、リアルタイム性、分散化など -- K 2003-11-06 (木) 20:14:54
• 何に対して"安全"なのですか? ＞昨日の私の書き込みでは”自分以外の悪意あるコードもしくは、バグを含んだコード”です。モジュールは自身の中が正しいことをに努力するのであって、自身の外側からの干渉にただしく動作することには努力しません。（外側からの干渉は色々あって、コード自体に改変されたり、メッセージが不正だったり、正式な手順で順番に呼び出して欲しいのにもう２度と呼び出されなかったりといったようなことです） -- Gaku? 2003-11-06 (木) 20:37:57
  • 追記：あれ。変ですね。外からのメッセージが不正かどうかはもちろんチェックします。外からの干渉にも努力するのか。上記の例からメッセージが不正だったりは除外した方が良さそうです。
• ところで「機構とポリシーを分けてカーネルを設計する」ということはどうやら私がマイクロカーネルという語から受ける印象とは異なるもののようです。例えば、関数コールのような方法でサービスが実装されていて、しかしこの関数が貼り付けられているメモリには別のバイナリを読み込めるような仕掛けを用意したＯＳはマイクロカーネルでしょうか？また、取り得る動作は外部からパラメータやスクリプトなどで指定できて、ＯＳ本体はその機構だけ提供していればマイクロカーネルでしょうか？ -- Gaku? 2003-11-06 (木) 20:44:57
• 私の受けるイメージとどこが違うのかに興味が沸いたので「機構とポリシーを分けてカーネルを設計する」とどういうイメージになるのかもう少し教えていただけるとありがたいです。（マイクロカーネルが何か？にはあまり興味が無くて、そのような機構はは何を目的にしていて、どうやってそれを実現しようとしているのかに興味があります） -- Gaku? 2003-11-06 (木) 20:46:17
• 追記：イメージが沸かないと、自分で勝手に思考を暴走させることになるので、質問してみました。 -- Gaku? 2003-11-06 (木) 20:51:24
• 追記２：ちなみに私がマイクロカーネルという語に持つイメージは、タスクに分割されている、タスク間の通信機構が提供されている。です。それで、なんでそういう機構を選択するのかなと。多分この機構でしか実現できない特徴がある。それは安全性の追及だ。と思考を進めてみたのが上の方の書き込みです。 -- Gaku? 2003-11-06 (木) 20:58:20
• 追記３：おや。shさんの書き込みから、機構とポリシーを分けてカーネルを設計する」ことについての目的は発見してしまいました。「複数の製品のラインアップを1つに統合する際、カーネル自体が多くのポリシーを持っていては複数のカーネルを1つのカーネルに統合するのは難しい」なるほど。カーネルが持つサービスが少ないことで多くのメーカが作った機器やドライバ・サービスなどを混在させることを目的にしているのか。では「機構とポリシーを分けてカーネルを設計する」＝マイクロカーネルと考えると「タスクに分割されている、タスク間の通信機構が提供されている」＝マイクロカーネルというイメージは間違いですね。 -- Gaku? 2003-11-06 (木) 22:42:05
• 追記４：↑そうでもないか。「タスクに分割されている、タスク間の通信機構が提供されている」この機構はタスクとして提供されているサービスの入れ替えがし易い。よって、複数の場所から持ってきたサービスを混合できるという目的を達成できる。という訳か。（あ、独り言で進めてますが、上の方で書いている疑問も依然有効なので、教えて頂ければ非常にうれしいです） -- Gaku? 2003-11-06 (木) 22:53:46
• 「機構とポリシーの分離というのは、マイクロカーネルの本質」ではないです。shさんも指摘しているとおり、Linuxのモジュールとか、RTSJ (Realtime Java)のスケジューラとか。 -- 2003-11-07 (金) 09:03:35
• マイクロであることを突き詰めていった結果、ポリシーを抽出すればもっとマイクロになるぞ、という流れと(私は)理解しています。だから私はずっと"現在的"マイクロカーネルという表記を貫いていたりします。(だれも気づいてくれなさそうだけど) -- もなか? 2003-11-07 (金) 09:07:14
• 分離によってカーネルは小さくなったし、パーソナリティは作りやすくなったし、一種のブレイクスルーではあったわけですが。 -- もなか? 2003-11-07 (金) 09:33:52
• K氏は難色を示していたようですが、水平/垂直という分類は、結構本質と思いますよ。 -- もなか? 2003-11-07 (金) 10:03:45
• そうなのです。それが分かりません。水平垂直の差は何でしょうか？どうすれば水平で、どうすれば垂直？ -- K 2003-11-07 (金) 11:29:10
• 私もきれいに説明できる自信がないのですが、依存関係、ですかねぇ。ちょっと説明文、考えてみます。 -- もなか? 2003-11-07 (金) 11:50:04
• オブジェクト指向な世界での"継承かインタフェースか"みたいな話にはなると思うのですが…。 -- もなか? 2003-11-07 (金) 11:51:15
• 結局zakuさんの「正直なところ私の周囲ではあまりマイクロカーネルとかモノシリックカーネルといった分類では考えていません。」という見解こそ、一番正しい気がしました。ということで、最大の敗北者は、「マイクロカーネル」などという名前でページを作ってしまった僕かな。僕にとってはマイクロカーネルに「固有」の特徴はもうなくなったらしい、ということを理解できたことが収穫でしたが、他の人には自明だったことでしょう。 -- K 2003-11-07 (金) 13:14:06

• ん? (主観的に)分類しない、分類の意味を見出せない、ってことですか? そういう結論もありとは思えますけれども。 -- もなか? 2003-11-07 (金) 15:52:08
• でもまあ、一応、説明文かんがえちゃいましたので、書き散らしておきますね。;) -- もなか? 2003-11-07 (金) 15:54:56
• 特定1つのメッセージ(受け渡しかたは何でもよいです)に着目します。このメッセージを、システムを構成する全てのコンポーネントがacceptできるとき、水平。そうでないとき、垂直です。ここで、acceptとは、メッセージを受信できることで、そのメッセージをどう内部処理するかというのは、また別の話です。 -- もなか? 2003-11-07 (金) 15:58:37
• いや、とりあえず垂直水平待ちではあります。もしこれがOSサービスモジュールの組み合わせ制限の程度の差とかなら、僕としてはあえてマイクロカーネルという語を使って物事を説明するのは、旧定義と新定義の混乱を招き、また新定義なら単にモジュール化といっても通用しそうなので、よくなかろう、というのが今の見解です。 -- K 2003-11-07 (金) 16:00:13
• (ここで使ったacceptは"俺定義"です念のため) -- もなか? 2003-11-07 (金) 16:00:26
• それはプロトコルのフォーマットが共通ということでしょうか？＞acceptできる -- K 2003-11-07 (金) 16:02:04
• サービスは原則としてみな同じインターフェースを持つ、ということなのかな？＞水平 -- K 2003-11-07 (金) 16:05:11
• そうです。通常、プロトコルは階層構造をなすでしょうが、低レベルのどこかで共通になっているという風に捕らえてください。OSI7層モデルを考えてもらってもいいですし、関数のコーリングコンベンションを考えてもらってもよいです。 -- もなか? 2003-11-07 (金) 16:07:42
• あ、ちがう。メッセージコンバータとかを経由してもacceptできればいいから、共通のインターフェースを持っていなければいけない、ということでもないのか。 -- K 2003-11-07 (金) 16:07:50
• なるほどこれはおもしろいかも。＞水平 -- K 2003-11-07 (金) 16:09:56
• なんで水平にしたかったのかという文献は読んだこと無いので、ここからさらに"俺説明"になっちゃうのですが -- もなか? 2003-11-07 (金) 16:21:13
• 親亀こけたら子もコケた、が嫌だった、ってなことだったのではと。 -- もなか? 2003-11-07 (金) 16:21:58
• たとえば、モノリシックカーネルのファイルサーバが死ぬと、上のアプリケーションは全部死にますよね。ファイルにアクセスしているかどうかは関係なく。 -- もなか? 2003-11-07 (金) 16:26:21
• なんで一蓮托生に死んでしまうかというと、アプリケーションは、ファイルサーバではなくて、モノリシックカーネルにアクセスしているからなのですよね。このニュアンス、判ります? -- もなか? 2003-11-07 (金) 16:29:56
• うーん、まあ、「なんで」を問い続けるとまた僕はダメ路線に行きそうなので警戒しているのですが、とりあえずちょっと考えてみました。親がこけたら子がこけるかどうかは、メッセージのフォーマットに関係なく、子がどのくらい自立的なのかにかかっている気がします。親が復旧するまで待てるとか、親が死んで再起動したときに対応できる、とか。・・・メッセージフォーマットが揃っていて嬉しいのは、デバッグ時にメッセージログを取るときとか、分散やるときじゃないでしょうか。つまり、サービス間のやり取りを「統一的に」モニターしたりコントロールする場合ですね。 -- K 2003-11-07 (金) 16:34:04
• アプリケーションは、ファイルサーバに至るまでに、色々な経路を通ります。Multicsみたいなリング保護モデルを考えてもらえると判りやすいかもしれません。水平型が好きな人は、これを俗に垂直型と呼びます。垂直型の利点は、差分開発が容易なことです。モニタからVMに至るIBMの歴史とも重なります。 -- もなか? 2003-11-07 (金) 16:34:32
• カーネルがファイルサーバに問い合わせて、それが返ってこない、だからカーネルが停止して全部停止、ということですか？ -- K 2003-11-07 (金) 16:36:28
• "子がどのくらい自立的なのか"まあ、そういう一面もありますけれどね。しかし、OSの目的って環境の問題をいかに隠蔽するかでしょう? たとえば、固定ディスクドライブに1バイト書くときに、回転が安定するまで空ループするようアプリケーションに強いるOSがあったとしたら、どう思います? -- もなか? 2003-11-07 (金) 16:43:14
• ああ、"サーバ"っていうと外部にあるイメージになっちゃいますね。モノリシックですから、カーネルの内部です。"ファイルシステム"というとファイルフォーマットと誤解されちゃいそうですし。困った。 -- もなか? 2003-11-07 (金) 16:45:05
• たしかにそれはよろしくなさそうです。＞空ループ　　そういうややこしい条件を付加するなってことですか・・・。 -- K 2003-11-07 (金) 16:46:07
• 話を元に戻して、垂直型の欠点は2つあります。 -- もなか? 2003-11-07 (金) 16:48:08
• 煎じつめると、まとめてこけるかどうかは、メッセージが非同期を想定しているかどうか、じゃないでしょうか？あとは、メッセージの流れが乱れる（通信相手がリセットしたとか、死んだとか）に対応できればよい、と。メッセージフォーマットの統一は、それとはちょっとずれている気がしないでもないです。 -- K 2003-11-07 (金) 16:49:53
• 経路にあるモジュールに不具合があると、その経路を通る全てのメッセージが配信されなくなります。(これはマイクロカーネルでも別の層で起きえます。その点については、また後ほど) -- もなか? 2003-11-07 (金) 16:51:41
• メッセージの同期/非同期とはあんまり関係ないです。モジュール間で、どのようにメッセージが配信されうるかという点に集中してみてください。 -- もなか? 2003-11-07 (金) 16:53:27
• なるほど、経由する部分が少なければ少ないほど、巻き添えを食らいにくいということか・・・。 -- K 2003-11-07 (金) 16:58:34
• まぁ、そういうことです。スター型ネットワークの代表である10Base-Tは、ハブが死ぬとハブにつながれた先は全滅ですね。バス型の10base-2には、そういうことはありません。 -- もなか? 2003-11-07 (金) 17:02:34
• "巻き添えを食らいやすい"というのが垂直型の欠点の1つめです。 -- もなか? 2003-11-07 (金) 17:04:13
• もう1つの欠点は、プロトコルの爆発による保守性の低下です。 -- もなか? 2003-11-07 (金) 17:06:39
• つまりこうですか？水平型でどうしてメッセージフォーマットが統一されるかというと、みんな極力ダイレクトにつながるから、フォーマットの種類が多いとやっていられない、ということなんでしょうか？・・・まあそれでも、別にメッセージフォーマットは違ってもいい気はする。水平化のメリットは分かるのですが、それはメッセージフォーマットとはあまり関係ないかも。・・・ただ何にしても、メッセージフォーマットが揃っていれば、カーネルは楽できそうな気はします。カーネルを小さくすることには貢献するかと。 -- K 2003-11-07 (金) 17:10:01
• はい、それはよくわかります。＞プロトコルの爆発による保守性の低下 -- K 2003-11-07 (金) 17:11:35
• 水平型と異なり、垂直型はどんな風にプロトコルを決めても他に影響がありませんから、好き勝手決められます。これは諸刃です。たとえば、「ここはスタック渡し」「ここはレジスタ渡しで返り値はEAX」「ここはレジスタ渡しで返り値はスタック」「ここは…」と、そのときの気分でやられたら、追いかけるのが嫌になりますよね。 -- もなか? 2003-11-07 (金) 17:11:41
• そうそう、上層のメッセージフォーマットは、(マイクロカーネルにとっては)どうでもいいです。他の例で挙げると、IPプロトコルは判らないかもしれないけれど、Ethernetフレームは判ることが期待できる、といった風な。関数呼び出しなら、コーリングコンベンションは、これじゃなきゃだめよ、というふうな。 -- もなか? 2003-11-07 (金) 17:17:08
• 水平型に関して質問です。マイクロカーネル機構の要請に、サービスを水平に提供すること、メッセージフォーマットを統一すること、というのはやっぱり含まれるべきなのでしょうか。今は含まれていても、また将来、「同じカーネルを垂直型OSの構築にも利用したいから」とか「プロトコルを3タイプにすることで状況に応じて最適なプロトコルを選べるようになった」とかで、これも緩和されてしまうということはありうるのでしょうか？・・・ありうるんだろうなあ。 -- K 2003-11-07 (金) 17:17:29
• 水平である以上、どこから何が飛んでくるか判りませんし、カーネルはモジュール間のメッセージを適切にリダイレクトしなければなりません。だから、(マイクロカーネルが理解できる)最低限のメッセージを決めなければいけません。L4の仕様書がほとんどプロトコル仕様書みたいになっているのは、そういう理由かと。 -- もなか? 2003-11-07 (金) 17:20:08
• 「水平型と異なり、垂直型はどんな風にプロトコルを決めても他に影響がありませんから、好き勝手決められます。」：これはちょっと微妙じゃないですか？水平型であっても、相手が決まっているとか、もしくは相手がそれを承知していれば、プロトコルは変えても他には影響しません。アプリとのインターフェース部分でそれをやられたら確かに泣きますが、あるサービスがグラフィックサービスへメッセージを送るときに、特別なプロトコルを使うのはありかもしれません。 -- K 2003-11-07 (金) 17:26:16
• "サービスを水平に提供すること"ここが結構問題なのですよ。機構として水平のトポロジを提供しましたと。でも、実際にパーソナリティを組むと、上層に垂直のトポロジができてしまいます。FATファイルサーバはvnodeファイルサーバを経由しディスクドライバに流れる、みたいな。結局水平なシステムなんて作れないじゃん、という苦悩の中から出た結論が"機構とポリシーの分離"だったのではと。 -- もなか? 2003-11-07 (金) 17:29:03
• それだ！＞適切にリダイレクト　　垂直であっても分散を考えるなら、リダイレクトは欠かせません。そしてリダイレクトするならフォーマットは共通仕様になっていることが断然有利です。・・・つまり僕が言いたいことは、メッセージフォーマットの共通化の必要性はよく分かるのですが、それが水平型と関係ある、という部分だけが「それはちょっと違うのでは？」と思うわけです。それだけです。 -- K 2003-11-07 (金) 17:29:36
• 逆質問："相手が決まっているとか、もしくは相手がそれを承知していれば、"というプロトコルを長期にわたり保守できますか? -- もなか? 2003-11-07 (金) 17:31:30
• いえいえ、リダイレクトは分散のために有用とは限りません。メッセージングは同期の一種です。OSの重要な役目に、実行コンテキスト間の同期機構の提供がありますね。 -- もなか? 2003-11-07 (金) 17:38:26
• いや、僕は保守性の話では全面肯定なのです。同じ事は垂直型にもいえます。プロトコルが覚えやすくて、共通化していれば、垂直型も保守しやすいし、モジュール単位で（プロトコル不一致に悩むことなく）、交換できます。・・・どうでしょうか？水平垂直と関わりなく、プロトコルの統一はメリットがあって、それをあえて水平のみにご利益があって垂直はだめ、というのは違うのではないかと。 -- K 2003-11-07 (金) 17:39:47
• "あるサービスがグラフィックサービスへメッセージを送るときに、特別なプロトコルを使うのは"ありですよ。いくつかのマイクロカーネルで「ペイロードにはユーザの好きなパケット乗せて構わない」という形式があります。マイクロカーネルは"機構しか提供しない"という考えだからできることかもしれません。 -- もなか? 2003-11-07 (金) 17:43:09
• ええと僕の論点は、「水平・垂直の区分がマイクロ・モノリシックを分ける」のは本当かというものです。メッセージフォーマットの統一が便利なことは了解です。そしてそれがマイクロカーネルの要請に含まれているというのも了解です。でも、サービスを水平にするか垂直にするかはポリシーなのではないか、つまり「水平じゃないとマイクロカーネルじゃない」は言過ぎなのではないか。本当にこれでいいんですか？ということだけです。 -- K 2003-11-07 (金) 17:44:21
• 垂直はだめ、と言った覚えはありませんよ。 -- もなか? 2003-11-07 (金) 17:44:41
• "水平 or not 水平"という話ではないのです。1つのシステムの内で、水平と垂直が共存することはありえます。モノリシックカーネル上にORBを載せた場合、ORBの世界は水平で、カーネルは垂直かもしれません。MachのBSDサーバやL4linuxは、水平の上に垂直がありますし。 -- もなか? 2003-11-07 (金) 17:49:36
• ああなるほど！やっとわかりました。「水平/垂直という分類は、結構本質と思いますよ」というのは、「主観で左右されるようなあいまいな分類ではない」ということを言われていたんですね。そっちだったのか・・・。 -- K 2003-11-07 (金) 17:49:44
• それと水平の本質は、acceptできるかどうか、つまりメッセージフォーマットが同じかどうかではなく、経由が最小限（というか理想的には「経由したとしても」カーネルくらいしか経由しない）ということであっていますか？ -- K 2003-11-07 (金) 17:52:20
• "水平でないマイクロカーネルは現存しない"ということなら、高い確率で言えるのではないかなぁ。 -- もなか? 2003-11-07 (金) 17:54:07
• "ああなるほど！やっとわかりました。" 判ってもらえて嬉しい。;) -- もなか? 2003-11-07 (金) 17:55:15
• "経由が最小限" はい。俺的定義は、そうです。今のところ、この定義でバカヤロウ扱いされたことはないです。少なくとも、今のところ。 -- もなか? 2003-11-07 (金) 17:58:24
• よくわかりました。ありがとうございます。 -- K 2003-11-07 (金) 17:59:26
• ああ、「マイクロカーネルは"機構しか提供しない"」ということこそ、うまい定義なのかもしれない。機構というとまた僕が混乱するので、インフラとあえて読み替えて、「マイクロカーネルはインフラしか提供しない」。これは分かりやすいかな。モノリシックでも、モジュール化しまくって、インフラとそれ以外に分離できるようになったら、その時点でマイクロカーネルと呼んでも差し支えない。・・・いいかも。 -- K 2003-11-07 (金) 18:05:51
• 仮にn層からなるOSを想定したとき、n層よりn-1層のほうがより"マイクロ"ですよね。帰納法により、1層が究極の"マイクロ"ですよね。これって、水平か垂直かと問われれば、水平ですよね。 -- もなか? 2003-11-07 (金) 18:07:36
• あれ？その「マイクロ」というのは、OSとしてマイクロ、という意味ですか？マイクロカーネルのマイクロって、カーネルがマイクロなことを言っていると思ったのですが、OSのレイヤ数がマイクロといっているのですか？ -- K 2003-11-07 (金) 18:11:42
• あれ? 混乱させてしまいましたか。カーネルが管理する同期通信の数です。層があれば、その境で同期通信が必要になりますね。層ごとに異なる同期通信が必要という前提です。 -- もなか? 2003-11-07 (金) 18:17:55
• より小さくを突き詰めたら水平になっちゃったということではないかと。今後ブレイクスルーがあって、垂直のマイクロカーネルが出るのかもしれませんけれどね。現在の私には思い浮かびませんけれども。 -- もなか? 2003-11-07 (金) 18:23:36
• つまり現代的マイクロカーネルってのはハードで例えるとマザーボードからバスだけ残した状態なのかなあ？ただ、水平分割や書式統一ってのはそれこそモジュール化って事のような気がするなあ。・・・で、そこからなんかイメージ的にHAL9000の引っこ抜いていくアレを連想してしまった。（ｗ -- 2003-11-07 (金) 18:32:06
• "バスだけ残した状態" ご承知かもしれませんが、ORBをソフトウェアバスと呼ぶ人もいます。 -- もなか? 2003-11-07 (金) 18:34:50
• バスだけ：うまいなあ。　　水平、書式はモジュール化っぽい：僕もその方が自然な表現な気がします。　　HAL：ウケました。 -- K 2003-11-07 (金) 18:35:25
• "モジュール化" 一般に、モジュール化設計では垂直に積んでいくこともできます。ですので、違います、というか的確ではありません。 -- もなか? 2003-11-07 (金) 18:38:27
• うん、でもマイクロカーネルも垂直に積んじゃいかんということでもなかろうと思うので、問題はないと思います。現状では、そういうマイクロカーネルは少ないのかもしれませんが（それをいったらサービスをカーネルモードで走らせるのも、たぶんかつては御法度だったわけですし）。 -- K 2003-11-07 (金) 18:43:50
• "マイクロカーネルも垂直に積んじゃいかんということでもなかろう" そう言い切るには、そういう構成の実装をもってくるか作るかする必要がありますね。 -- もなか? 2003-11-07 (金) 18:45:36
• ああそうか「現代的」マイクロカーネルだから、つまり「未来的」じゃないから、水平に限定してもいいってことなのかな？ -- K 2003-11-07 (金) 18:47:32
• "サービスをカーネルモードで走らせるのも、たぶんかつては御法度" だったかどうかも判りません。JavaのようなVM型の場合、保護リングの無い構成もありえます。 -- 2003-11-07 (金) 18:49:09
• ソフトウェアですから、理論さえあればあとは何でもありですが、背景が整わないうちに拡大をOKにすると、単なるオカルトになりかねません。 -- もなか? 2003-11-07 (金) 18:51:43
• うんと、僕の読んだ本では、VM型はマイクロカーネルとかモノリシックとかとは別に考えて、また一つの分類になっていました。そこでは、雰囲気としてはVMインタープリタがカーネルみたいな感じで、VM上で走るサービスがマイクロカーネルでいうところのサービスみたいになっていました。VM上のサービスは、VMインタープリタによって変なところをアクセスしないようにチェックされているわけです（これは僕の印象であって、何も一対一対応があるわけではないと思います）。もしVM部分をクルーソーのようなハードウェア層の一部と考えるなら、それはカーネルがマイクロコードとして組み込まれたCPU、みたいに考えるのかもしれません。 -- K 2003-11-07 (金) 18:56:38
• たしかに。＞オカルトになりかねない　　しかし、物が出てきてからじゃないと、なんともいいがたい、というのもなんか情けないですね。OSを書いてみないと分からないというのは、結局マイクロカーネルはこういうものだという何かがあると信じることは実は幻想で、結局はその場の雰囲気でてきとーに決めちゃっている、ということなんでしょうか？・・・できればそんな変なことはしないで、マイクロカーネルはこういうもの、と腰をすえて、もしそれに収まらないものが出たら、別の名前にしてほしいところです。ってもなかさんに言ってもしょうがないですが（すみません）。 -- K 2003-11-07 (金) 19:04:40
• 結局僕たちは、自称マイクロカーネルOSの実態から、マイクロカーネルというのはこういうものだろうと推測しているに過ぎないのだろうか？・・・誰かが、「これもマイクロカーネルだぜえ」ってきたとき、それは違うよ、ということはできないのだろうか？仮にできたとして、それは理論的な説明ではなくて、識者による多数決なのだろうか？識者が持っている定義を明文化して固定することはできないのだろうか？・・・機構の名前なのに、どんな機構なのか変わりうるなんて・・・。目的が変わるのは違和感がなくなったけど、これはちょっと慣れるのに時間がかかりそうです。 -- K 2003-11-07 (金) 19:11:58
• すいません、そこはモジュール化の一種とするべきでしたね。どうもモジュール化って縦に分割って先入観で考えてしまうもので・・・まあ、そういうような言葉に表れている意味以上の固定概念をあまり定義にも持たせるべきではないのかもしれませんね、単に意味が広いというだけなら補足するだけで済むのですが、不用意に限定してしまって他にその言葉にふさわしいものが出てきた時にそれが使えないというのは困るというか。 -- 2003-11-07 (金) 20:26:12
• うわ。すごい増えてる。読むの大変だ・・。全部読んでないのであれですが、とりあえず、『「機構とポリシーの分離というのは、マイクロカーネルの本質」ではないです。』＞自分の持ったマイクロカーネルのイメージが間違っていないようなので安心しました。２つのこれもマイクロカーネルとか言わないよね？が否定されなかったらどうしようかと思ってました。それと「僕にとってはマイクロカーネルに「固有」の特徴はもうなくなったらしい、ということを理解できたことが収穫でしたが、他の人には自明だったことでしょう。」私はこれにちっとも納得しないので自明ではありません。 -- Gaku? 2003-11-07 (金) 22:41:12
• あー。マイクロカーネルに「固有」のマイクロカーネルが優位な特徴がなくなったらしい。ならばそれっぽいかも知れません。モノ（ここでは機構ですが）には必ず特徴があるはずです。まぁその特徴が劣っていたりすることはあり得ますが、特徴がないものなんてあり得ないと思っています。 -- Gaku? 2003-11-07 (金) 22:45:23
• "自称マイクロカーネルOS" というか、実装が先行して「これになんて名前つけるべ?」ということも往々にしてあると思うのですけれどね。現在多くの人がマイクロカーネルに分類するMINIXですが、それを用いた教科書である「MINIXオペレーティングシステム」第1版の索引に(そしてたぶん全編のどこにも)「マイクロカーネル」という語は出てこないのですよ。 -- もなか? 2003-11-07 (金) 22:57:25
  • あ、これ私へのメッセージですか？Kさんとのやり取りだと思って読みました。それで、実に的確な指摘です。「MINIXオペレーティングシステム」に、Minix 的な OS こそが the micro カーネルだという記述を見つけられなかったので。 -- Gaku 2003-11-08 (土) 4:00
• "推測しているに過ぎないのだろうか？" これは私には答えるための知識はありません。誰かが形式的数理的なマイクロカーネルの定義を示しているかもしれませんが、私は知りません。知らない以上、"垂直に積んじゃいかんということでもなかろう"と問われれば(私は)否定はできません。ただ、垂直に積むということは、機構が複数になることを意味するので(1つであれば水平に置換できるから)、水平型に比べてカーネルの規模は大きくなり「マイクロカーネル」と呼べるかどうか疑問ではあります。俺的推測なので、そこのところお汲み取りくださいませ。 -- もなか? 2003-11-07 (金) 23:12:50
• んー。やっぱりもう一度質問してみます。関数コールのような方法でサービスが実装されていて、しかしこの関数が貼り付けられているメモリには別のバイナリを読み込めるような仕掛けを用意したＯＳはマイクロカーネルでしょうか？（すべてのサービスは←のような機構で実装されていて、さらに、これらは水平とみなせる程度にカーネルの上に直接乗っかっているというイメージです） -- Gaku? 2003-11-07 (金) 23:18:04
• 質問した理由。１．これはマイクロじゃない。これはマイクロ。と言えるなら、マイクロカーネルという名前があらわす機構の範囲があるはずです。ならば、これこれこういう機構のこと。と表現できるはずです。（機構の形が表現できれば、その機構が持つ特徴について考えることができます。それらの特徴が、他の別の機構が持つ特徴とくらべて優れているか？また、持っている特長が他の機構と比べてどう違うか？なども考えることができるはずです。） -- Gaku? 2003-11-07 (金) 23:21:30
• 質問した理由。２．メッセージ、メッセージと言っていますが、関数コールは十分メッセージのやり取りみなせると思います。議論を詳細化するためにはメッセージのもう少し具体的な定義をする必要があると思います。（具体的な定義はいくつかあっても構いませんし、どんなメッセージでも。ということでも構いません。） -- Gaku? 2003-11-07 (金) 23:23:28
• 質問した理由。３．ある程度の大きさに分割されたモジュールがどの程度、保護されるべきなのかが見えるかもしれない。（自分のイメージでは単に関数的なものはあまり保護しようと言う意図が見えません。逆にタスクに独立することは保護できる可能性があるので、その意図がある。かもしれないと思えます。） -- Gaku? 2003-11-07 (金) 23:26:02
• 追記：理由３は蛇足でした。 -- Gaku? 2003-11-07 (金) 23:31:27
• "質問した理由。１．" まず誤解があって、マイクロカーネルはメッセージ配信機構をもつことがありますが、メッセージ配信機構そのものではありません。具体的にどんな機構にするのかは一般に選べますし、選択が性能を決める場合もあります。 -- もなか? 2003-11-08 (土) 00:13:56
• "質問した理由。２．" 一般論をするのなら、 カーネルが理解できるヘッダのついたバイナリ列という定義で十分なはずです。実装するならどんなヘッダをどのような手段で通信させるかという話にはなるでしょう。 -- もなか? 2003-11-08 (土) 00:18:37
• "質問した理由。３．" 何度も話に出たとおり、現在的マイクロカーネルは、モジュールが保護されるべきかどうかについて何も語りません。 -- もなか? 2003-11-08 (土) 00:20:29
• なるほど。メッセージ配信機構を持っていなくてもマイクロカーネルと呼びうる訳ですね。では確かに質問は的外れです。 -- Gaku? 2003-11-08 (土) 00:33:58
• それで、次の質問を思いつきました。マイクロカーネルはカーネルが非常に小さいことで、それ以外のことには関知しない。カーネルと定義されるものは、そのＯＳで常に使われ続ける部分のことである。という定義は正しいでしょうか？（この定義で見た場合、関数コールのような方法でサービスが実装されていて、しかしこの関数が貼り付けられているメモリには別のバイナリを読み込めるような仕掛けを用意したＯＳはマイクロカーネルである。というのは正しいでしょうか？） -- Gaku? 2003-11-08 (土) 00:41:06
• いえいえ、書き方が悪かったです。電話はダイヤルという機構を持つことがありますが(というより普通持ちますが)ダイヤルそのものではありません。具体的にどんな機構にするのか(プッシュかパルスか、とか)は一般に選べますし、選択が性能を決める場合もあります。 -- もなか? 2003-11-08 (土) 00:41:19
• 質問をした理由。定義について共通の理解に至れれば話を先に進められるかもしれません。（この場合、話を先に進めてないの私なので恐縮ですが） -- Gaku? 2003-11-08 (土) 00:44:30
• あんまりいい例じゃないなぁ>私 -- もなか? 2003-11-08 (土) 00:45:36
• 追記：しつこく、関数型のコールの例を出すのは、これがマイクロカーネルだとは今の自分は思っていないからです。また、関数のコールは十分メッセージのやり取りだとみなせると思います。（メッセージの定義がされていなければ大きな範囲で定義することが可能なので）それで、一般的な定義では、メッセージは、ヘッダのついたバイナリ列という定義。だと思います。だとすれば、ここで述べているメッセージングの機構は関数コールやコールバック関数的なものは除外して良いことになります。 -- Gaku? 2003-11-08 (土) 00:48:49
• それで、質問の回答を頂いたところによると、マイクロカーネルがメッセージングの機構を持つ。というのは正しいようです。（ここで言うメッセージはヘッダのついたバイナリ列という定義。と定義できました。） -- Gaku? 2003-11-08 (土) 00:50:50
• "除外して良いことになります~ なぜですか? -- もなか? 2003-11-08 (土) 00:51:52
• それで次の質問です。マイクロカーネルとはヘッダのついたバイナリ列と定義されるメッセージをやり取りできる機構を持つ。だから、関数コールのような方法で出来うる限りほとんどのサービスが実装されていて、しかしこの関数が貼り付けられているメモリには別のバイナリを読み込めるような仕掛けを用意しているが、ヘッダのついたバイナリ列からなるメッセージングの機構を提供していないＯＳはマイクロカーネルとは呼べない。というのは正しいでしょうか？ -- Gaku? 2003-11-08 (土) 00:54:15
• あ。除外しちゃダメでしたか。じゃぁ上の質問のはまだちょっと早いですね。どうしようかな。 -- Gaku? 2003-11-08 (土) 00:55:14
• あーと。関数コール。をヘッダのついたバイナリ列である。と定義されるメッセージと見なせる理由は、例えば、引数などでバイナリのデータを渡しているから。と言うことでしょうか？ -- Gaku? 2003-11-08 (土) 00:56:54
• 自分が、関数コール。をヘッダのついたバイナリ列である。と定義されるメッセージと見なせない。と判断した理由は、関数コールをバイナリのデータを渡す行為。にカウントしなかったからです。（例えば、関数コールって言ったって、ＩＰに値を代入する行為なんだから、バイナリ渡してると言える。とか、理由はどんなでも良いので、関数コール。をヘッダのついたバイナリ列である。と定義できる理由が分かると、納得しやすいです） -- Gaku? 2003-11-08 (土) 00:59:10
• "引数などで" まあそんなところです。特にシステムコールなら、システムコール番号を内部的に付加してカーネルに渡していますね。考えようによっては、これは立派なメッセージです。蛇足ですが、純粋オブジェクト指向言語では、メソッド(関数)の呼び出しと同様の操作を、オブジェクトにメッセージを送信する、などと言います。 -- もなか? 2003-11-08 (土) 01:01:38
• 追記：マイクロカーネルってメッセージングの機構を提供しているＯＳですか。と私が書いて、さらにここで言っている、メッセージって何かを定義して欲しい。という質問に対して、「一般論をするのなら、 カーネルが理解できるヘッダのついたバイナリ列という定義で十分なはずです。」と答えていただいたので、マイクロカーネルがメッセージングの機構を持つ。といったときのメッセージングの機構は「ヘッダのついたバイナリ列という定義」であると解釈しました。 -- Gaku? 2003-11-08 (土) 01:02:46
• なるほど。了解しました。メッセージングの機構は「ヘッダのついたバイナリ列という定義」で、注釈として関数コールなどもこの定義の範疇にある。とできました。さらに、マイクロカーネルは先ほど定義したメッセージングの機構を持つ。で正しそうです。 -- Gaku? 2003-11-08 (土) 01:04:57
• それでは、以上のマイクロカーネルの定義により、関数コールのような方法でサービスが実装されていて、しかしこの関数が貼り付けられているメモリには別のバイナリを読み込めるような仕掛けを用意したＯＳはマイクロカーネルである。は正しい。いかがでしょうか？ -- Gaku? 2003-11-08 (土) 01:06:27
• もう少し、定義が足りないかな。以上の定義に加えて、マイクロカーネルはカーネルが非常に小さいことで、カーネルと定義されるものは、そのＯＳで常に使われ続ける部分のことである。も追加したほうが良いでしょうか？（小さいが微妙ですが、機能の種類が少ないとかで表現できるかな？） -- Gaku? 2003-11-08 (土) 01:08:08
• なんだか、リアルタイムなやり取りが何度かあったので、一応、今日はもう寝るので。というコメントを残しておきます。それでは。 -- Gaku? 2003-11-08 (土) 01:10:01
• 実装が想像できないのですが…ITRON仕様でいう拡張SVCだけが存在するような実装でしょうか? それとも間接参照とダイナミックローディングが組になったようなもの? -- もなか? 2003-11-08 (土) 01:10:18
• あぁ。返事したくなってしまった。実装が想像できないとは？えーと、「関数コールのような方法でサービスが実装されていて、しかしこの関数が貼り付けられているメモリには別のバイナリを読み込めるような仕掛けを用意したＯＳ」の実装のことでしょうか？ -- Gaku? 2003-11-08 (土) 01:12:37
• あっと。それと定義が良さそうだったら、それで良い。もしくはもう少し付けたしがあるんだけど。といってもらえるとありがたいです。 -- Gaku? 2003-11-08 (土) 01:16:19
• それで、「関数コールのような方法でサービスが実装されていて、しかしこの関数が貼り付けられているメモリには別のバイナリを読み込めるような仕掛けを用意したＯＳ」というのも色々あると思いますが、間接参照とダイナミックローディングが組になったようなものでもＯＫだと思います。(それで、ここでは、間接参照とダイナミックローディングが組になったようなもの。で、話を進めてもらえるとありがたいです。) -- Gaku? 2003-11-08 (土) 01:19:43
• 今度こそ、眠。 -- Gaku? 2003-11-08 (土) 01:21:49
• 逆質問：そのカーネルはマイクロカーネルでしょうか違うでしょうか。また、そのように主張する根拠はどこでしょうか? -- もなか? 2003-11-08 (土) 01:44:50
• せめて"俺的定義は○○であるから、これは□□である"というところまで詰めてもらえないと、無駄な時間がかかりますよ。お互いに。 -- もなか? 2003-11-08 (土) 02:04:29
• 実はまだ起きていました・・ていうか寝るのに失敗しました。それで、「逆質問」への回答が以下少し続きます。 -- Gaku? 2003-11-08 (土) 02:20:00
• それで、質問についてですが、『「関数コールのような方法でサービスが実装されていて、しかしこの関数が貼り付けられているメモリには別のバイナリを読み込めるような仕掛けを用意したＯＳ」というカーネルはマイクロカーネルでしょうか違うでしょうか？そのように主張する根拠はどこでしょうか？』で良いでしょうか。（それの部分を埋めさせていただきました。間違っていたらそれが何かご指摘ください。） -- Gaku? 2003-11-08 (土) 02:23:07
• 質問の回答に当たってある程度明確にしたいことが幾つかあります。１．「というカーネルはマイクロカーネルでしょうか違うでしょうか？」について「というカーネルはマイクロカーネルでしょうか違うでしょうか？」で間違いありませんか？「というＯＳはマイクロカーネルでしょうか違うでしょうか？」ではありませんか？（というカーネルはマイクロカーネルである。という質問は、カーネルについてしか言及していないので、カーネルの外に追い出したサービスについて言及できません。なので、カーネルの外に追い出したサービス間にメッセージングの機構があるorないことを前提に話すことができません。）なので、以下の回答では「そのＯＳはマイクロカーネルでしょうか違うでしょうか。また、そのように主張する根拠はどこでしょうか? 」と修正させていただいて回答します。-- Gaku? 2003-11-08 (土) 02:28:17
• ある程度明確にしたいこと。２．「関数コールのような方法でサービスが実装されていて、しかしこの関数が貼り付けられているメモリには別のバイナリを読み込めるような仕掛けを用意したＯＳ」の実装として「間接参照とダイナミックローディングが組になったようなもの。」を考える。この質問への回答に当たっては、他の実装を考えない。-- Gaku? 2003-11-08 (土) 02:29:17
• ある程度明確にしたいこと。３．「そのＯＳはマイクロカーネルでしょうか違うでしょうか。」に回答するためには、私が考えるマイクロカーネルのある程度限定できる表現が必要です。この私がマイクロカーネルはこれだと書きたいものが現状２つあります。１つは、昨日から今日にかけてもなかさんに質問に答えていただいたなかで、これは信じるに足るかもしれない。と思い始めたマイクロカーネル像でこれをＡとします。もう１つは、私がこのページに最初に書き込み始めたときにマイクロカーネルはこれだ。と思っていたマイクロカーネル像でこれをＢとします。 -- Gaku? 2003-11-08 (土) 02:34:33
• ある程度明確にしたいこと。４．マイクロカーネル像Ａ．マイクロカーネルの定義は主に３つである。１つはカーネルが非常に小さいことで、カーネルと定義されるものは、そのＯＳが起動している間中、使われ続ける部分のことである。（カーネルが小さいとは機能の種類が少ないこととする）２つ目は、カーネルの外に追い出された部分は適度な大きさに分割されている。分割の方法は任意である。３つ目は、カーネルの外に追い出された部分の間でヘッダのついたバイナリ列と定義されるメッセージをやり取りできる機構を持つ。注釈として関数コールなどもこのメッセージの範囲である。 -- Gaku? 2003-11-08 (土) 02:44:01
• ある程度明確にしたいこと。５．マイクロカーネル像Ｂ．マイクロカーネルの定義は主に３つある。１つ目は、ＯＳの出来る限り多くの機能がタスクで実現されていることである。（ここで使うタスクとは、例えば、１ＣＰＵ１サービスというような、タスク内で使える資源が、タスクの外からなるべく分離した状態を指して言う。実際に即して言えば、80486のTSSによって実現されるタスクという機構が、１ＣＰＵ内に複数のＣＰＵがあるかのように見せることが出来る。というような外部から分離するための単位という捕らえ方）２つ目は、タスクに分離されたそれぞれの機能間でのメッセージングの機構を提供すること。（ここで、メッセージとは、ヘッダのついたバイナリ列と定義されるメッセージのことで、関数コールなどは含まない。実際に即して言えば、共有メモリにバイナリ列をコピーすることでメッセージの受け渡しをするようなこと）３つ目は、ＯＳの機能をタスクに分割したが、このタスクがそれぞれの間でなるべく干渉しないように努力するカーネルがあること。 -- Gaku? 2003-11-08 (土) 02:56:19
• ある程度明確にしたいこと。６．ダイナミックローディングによって、読み込まれる部分は、適度な大きさに分割されている。また、ＯＳのできる限り多くの部分は、ダイナミックローディングによって、読み込まれる部分によって、実現される。（この２つの条件は、元の質問に書き損じていました。本来なら、２つの条件を満たす場合と満たさない場合を条件分けして回答するべきですが、ここでは２つとも満たす場合について解答します。） -- Gaku? 2003-11-08 (土) 03:15:18
• 回答１．マイクロカーネル像Ａ．の場合。「間接参照とダイナミックローディングが組になったようなもの。」はマイクロカーネルである。その様に主張する根拠は、ダイナミックローディングで読み込まれる部分は「ＯＳが起動している間中、使われ続ける部分」ではないのでカーネルではない。カーネルの外に追い出された部分は関数コールのような方法で呼び出されている、のでメッセージングの機構を有する。カーネルの外に追い出された部分は適度な大きさに分割されている。 -- Gaku? 2003-11-08 (土) 03:17:06
• 回答２．マイクロカーネル像Ｂ．の場合。「間接参照とダイナミックローディングが組になったようなもの。」はマイクロカーネルではない。その様に主張する根拠は、関数コールのような方法は、マイクロカーネル像Ｂで述べるている、メッセージングではない。（もう１つあって、ここで私がタスクと表現しているものと一致していないという理由もありますが、タスクが微妙なのでカッコつきにしておきます） -- Gaku? 2003-11-08 (土) 03:20:14
• 今日の夕方までは、マイクロカーネル像Ｂ．を信じていました。が、今はマイクロカーネル像Ａ．も疑っています。大分長くなりました。申し訳ありません。「無駄な時間がかかりますよ。お互いに。」とのことですが、もなかさんがもう時間は掛けられないと判断したならば、読み捨てください。理解が得られたらうれしいという希望で書き込んではいますが、無理はしていただきたくありません。今日は質問へ回答していただいたことで理解が深まりました。ありがとうございます。 -- Gaku? 2003-11-08 (土) 03:21:36
• と、ここまで書いて、上でもなかさんとＫさんが面白いやりとりをしていることに気づきました。（もなかさんのマイクロカーネルに対する俺的定義てのを見かけてないなぁと思ってたのですが、今日の上の方の水平に積んだときのレイヤ数が少ないほうが。っていう定義と理解しました。） -- Gaku? 2003-11-08 (土) 03:31:45
• 現在の自分の見解をまとめ直しました。（話を先に進めていなかったお詫びの気持ちも含んでいます） -- Gaku? 2003-11-08 (土) 14:11:41