[OSASK 1513] Re: micro kernel.

[Hidemi KAWAI <kawai !Atmark! imasy.or.jp>]

  こんにちは、川合です。


nabe さんは 2001/02/17 01:44:21 の「[OSASK 1512] Re: micro kerne
l(Re: memory management).」で書きました：

>ただ問題は、川合さんもおっしゃる通り、
>「どのレベルまで」をやるかという程度が重要だということだと思います。
>＃現状では、そんな OS が窓しかないのは悲しいところですが……

  ？？？・・・すみません、おっしゃりたいことが僕には分かりません
でした。

  程度が重要だという主張はもちろん分かります。

  その次の、「そんなOSが窓しかない」というのがよく分かりません。
窓というのはWindowsのことを指しているんだと解釈しているのですが
、Windowsはその程度のバランスがとれたOSだという主張なのでしょう
か？・・・そういう風におっしゃっているように読めないこともないん
ですが、この解釈にいまいち確信が持てないのです。

>>  なんていうか、僕の「マイクロカーネル」のイメージは、タスクの乱
>>発であるように思われます。
>別に違うタスクである必要性はなくて、ひとつひとつのモジュールが
>弱連結（私が勝手に使ってる言葉。独立性が高いという意味）であれば
>スマートなように今は考えています。

  それは僕と同じですね。

  僕がなべちゃんさんと違いを明確にしておくと、この開発方針を「マ
イクロカーネル」と言うか言わないかの違いだけです。

>>これは、カーネルやDLLの乗り換えが容易になることを意味していて、
>>バージョンアップや開発競争を促進する効果があると考えています。
>>システムが向上すれば、アプリの開発もきっとやりやすくなることでしょう。
>
>乗り換えることが可能になったり、無限の拡張性ってのは魅力でして
>私も好きなのですけど、そんなときいつも悩むのは（アプリの）互換性や
>サービス対象の見つけかたです。
>
>例えば、「こんなサービスください」って投げると
>「そんなサービスしますよ」って返ってくるものだと思ってるんですが、
>その『こんな』や『そんな』ってどうやればいいんだろう。
>
>＃簡単なことを難しく悩んでるだけかもしれない　＞私

  少なくとも、僕の構想ではこの問題は全く生じません。

  なべちゃんさんのスタンスは、

  「複数のシステムコール体系が存在し、共存している。アプリはその
全てのシステムコール体系に対応するために、自分に接続されているシ
ステムコール体系で目的を達するにはどのようなコマンドを実行しなけ
ればいけないかを判断しなくてはいけない。そのためのコマンドを作る
のはとても難しいことだ。」

というものです。確かにこの文を読めば読むほど回避しがたい問題だと
思えてくるでしょう。

  僕はこの問題を以下のように解決します。

  「複数のシステムコール体系が存在し、共存している。しかしアプリ
はその中の１つのシステムコール体系にのみ対応すればよい。プログラ
マーが便利だと思うものを選べばいいだろう。アプリは自分が指定した
システムコール体系だけで目的を達すればいい。だからコマンドを知る
ためのコマンドなどは必要ない。

  もちろん、ほとんどの場合においてアプリが指定したシステムコール
体系と実際に機能しているシステムコール体系は異なるだろう。つまり
コマンド番号やコマンドフォーマットなどが異なっている。この差異は
シェルの責任で吸収される。もちろん、実際にシェル内でコマンドの再
発行を行うわけではなくて、シェルはコマンドの再発行をやってくれる
ルーチンをアプリに接続するだけのことである。」

  結局、アプリはだまされていることになります。ぐいぐい00のコマン
ドで書かれているアプリは、本当にぐいぐい00を呼んでいると思ってい
ます。しかし実際はぐいぐい01が走っていて、その差異を埋めるために
「ぐいぐい00−ぐいぐい01ブリッジ」がアプリに接続されていたりする
わけです。

  アプリはぐいぐい00とぐいぐい01の両対応でなくても、両対応になる
んです。将来たくさんのシステムコール体系が生まれるでしょう。そし
て新しいシステムコール体系を提唱する人は、このブリッジもあわせて
用意することになります。もし主要な他の体系とのブリッジが用意でき
なければ、プログラマーに支持されず、受け入れられないと思います。
逆にブリッジさえ用意できれば、面倒なエミュレーターを開発すること
なしに今までの多くのアプリケーションを対応させることができます。

  アプリが複数のシステムコール体系に対応して書かれた場合、まず間
違いなくコードが増えます。僕の方法はそんなことは起きません。さら
に僕の方法の中になべちゃんさんのスタンスを内包させることもできる
という点にも注意してください。僕はアプリがシステムコール体系を判
定するという手法を推奨しませんが、否定しません。もしそうあるべき
だという人がいたらそのようなシステムコール体系を提唱してください
。OSASKはその体系も受け入れられます。

  僕の方針では、「アプリをだます」というのが重要です。アプリがシ
ステムに対しバージョンを聞くなんてことは、「だまし」を不十分にし
ますから、僕は嫌いです。バージョンを尋ねるコマンドを作れといわれ
れば作ってもいいですが、そのコマンドの説明に、このバージョン取得
コマンドは「だまし」に応じて本当のバージョンを返さないことがよく
ある、と注意を書きます。

  本当のバージョンが分からないなら、そもそもバージョンを聞く必要
なんてあるんでしょうか。実際に走っているバージョンがver.1.0でも
ver.2.0でもver.3.0でも、バージョンコマンドの結果はver.2.0だった
りするわけです。僕はこんな結果の分かった質問をする意味はないと思
います。だからアプリからのバージョンコマンドは、コマンドそのもの
を作っていませんし、作る予定もありません。システムからの問い合わ
せにはもちろん正確に応じる意味があると思っています。したがってシ
ェルはバージョンコマンドを発することができますし、その時は正しい
バージョンが通知されます。

  「アプリはシステムに従う」、「アプリはシステムに合わせる」とい
うニュアンスが一般的なのかもしれません。しかし、僕が目指すOSASK
アプリケーションのありかたは逆です。「システムはアプリの要求に合
わせる義務を負う」のです。アプリがver.2.0を要求すれば、システム
はver.2.0を用意するか、もしくはver.2.0のコマンドをver.1.0やver.3
0に変換するためのブリッジを用意しなければいけません。

>>  アプリが復元できない情報をドライバが保持すればいいだけです。た
>>とえばビデオドライバーなら、VRAMのイメージを持っておくとか。
>設定した画面モードとか、例えばウィンドウマネージャなら、
>そのウィンドウを移動してる途中……とか、
>（システムドライバ内で）検索（例）してる途中とか、
>そういうのって、タスクディレクトリに入るのですよね。
>各々のタスクに対して取れないですよね。

  この質問は、ウィンドウシステムを前提になされているようなので、
僕もそれを前提にお答えします。

  まず、設定した画面モードはもちろん保存する意味があるでしょう。
しかし、VRAM全体を保存しておく意味はありません。そのウィンドウが
表示されている範囲だけで充分でしょう。

  システムは、保存する直前にシステム内のそのアプリに関する情報を
あらいざらいタスクディレクトリに書き出します。・・・つまり、タス
クディレクトリ内のものをまとめさえすればそれでタスクセーブができ
るというのはおおざっぱな説明なのであって、いろいろ他にも保存すべ
き情報はあります。ですから、タスクディレクトリに注目しすぎるとタ
スクセーブ全体を見失ってしまうかもしれません。

>>C言語もこれを認めればとりあえずマルチセグメントを使えるよう
>>にはなります。
>あんまり関係ないけど、High-C は使えますね。　>far
>ただ、柔軟性はなかったように思いますが…… >High-C

  はい。そういう意味ではHigh Cは優秀です。lcc-win32はもしかした
らfarポインタをサポートしているかもしれないのですが、今の僕には
やり方が分からないので、使えません。High CもフリーだったらOSASK
の標準にすえたのですが・・・。

>ヒープメモリの確保を下の伸びてって、スタックは上に伸びていって……。
>とすると、一番いいのは、
>
>　　上↑スタック
>　　　　静的変数
>　　下↓ヒープメモリ
>
>で、上の方に余計にリニアアドレスを割り当てておく……って
>ことになるんでしょうかね。

  そうでしょうね。

  ええと、ここの話題には直接関係無いのですが、インテル系では、ア
ドレスが数値的に小さな値から大きな値に増えていくのが「上方」で、
逆に大きな値から小さな値へ減っていくのが「下方」です。・・・また
２つのアドレスがあるときに、アドレスの値が小さい方が「下位」で、
大きい方が「上位」です。たとえば、0x00001234と0x12345678を比べた
ら、より上位なアドレスは0x12345678です。

  なべちゃんさんの説明は前のメールから上位下位が逆になっているよ
うに思います。最初、僕は混乱しました（笑）。

  なお、この上位下位は、AXをメモリaにストアした時に、ALがaに、AH
がa+1に書き込まれることと関連しているようです（だから、aが下位で
a+1が上位）。要するにendianの問題ですね。

>>適当に1MBほどのメモリを割りあえててその中に必要な分だけ
>>ページを貼り付けるしかないのでしょう。
>おそらく同じ結論ですね……。

  そのようです。

>   上     下
>CS =========
>DS ---------*********
>
>"===" を "---" にコピーしなくても、
>同じ物理メモリを示すようにして、DS の方の "---" のページには
>書き込み属性を付けなければ（ページテーブルに）可能は可能では？
>
>＃ただ、こんだけのためにそれだけするのも大袈裟ですが……

  多分こんなことは知っていて書かれているんだと思いますが、一応
他の方も読んでいるでしょうし、補足しておきます。Cコンパイラで生
成される実行ファイルは次の３つの部分を持ちます。

・実行ファイルヘッダ（メモリにはロードされない）
・実行コード群(C)
・staticデーター初期値イメージ(S)

  これをWindowsなどで普通にロードした時は、以下のようにメモリに
配置されます。

CS     CCCCCCCCCSSSSSS???????????????????|(limit)
DS,SS  CCCCCCCCCSSSSSS???????????????????|(limit)

?の部分は、初期化されていない領域で、スタックなどが含まれます。
このうち、実際に必要なのは（＝アクセスされるのは）、

・CSでは、「C」の部分だけ
・DSでは、「S」と「?」の部分だけ

です。つまり、

CS     CCCCCCCCC|(limit)
DS,SS           SSSSSS???????????????????|(limit)

としてしまっても問題は起きません（空白部分はページにマップすらし
ないという意味です）。

  なべちゃんさんの方法は一見すると

CS     CCCCCCCCCSSSSSS|(limit)
DS,SS  CCCCCCCCCSSSSSS???????????????????|(limit)
      (rrrrrrrrrrrrrrrwwwwwwwwwwwwwwwwwww)

という方法のように見えますが、そうではないんですよね？（rはリー
ドオンリーページ、wはリードライト可能なページ）。厳密には、

CS     CCCCCCCCCSSSSSS|(limit)
DS,SS  CCCCCCCCCSSSSSS???????????????????|(limit)
      (rrrrrrrrrwwwwwwwwwwwwwwwwwwwwwwwww)

にしないとコードが走りません。static変数は参照だけでなく書き込
みもされますから。

  以上の補正も含めて考えれば、なべちゃんさんの方法は意味あると
思います。でも、上記のrの部分はどうせ不要なのですから、

CS     CCCCCCCCCSSSSSS|(limit)
DS,SS           SSSSSS???????????????????|(limit)

の方が優れていると僕は思います。


  それでは。

--
    川合 秀実(KAWAI Hidemi)
川合堂社長 / OSASK計画総指揮 / カーネル開発班
E-mail:kawai !Atmark! imasy.org
Homepage http://www.imasy.org/~kawai/