[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]

[OSASK 1510] micro kernel(Re: memory management).

  こんにちは、川合です。


nabe さんは 2001/02/16 06:03:08 の「[OSASK 1508] Re: memory mana
gement.」で書きました：

>いや全然関係ないです。モジュール化です。
>しごく当たり前すぎてるだけなのかも（汗）
>マイクロカーネルって分かりますよね、そのことを言ってるんです。
>そういう方法で、メモリを管理させたらスマートかな。

  「マイクロカーネル」という単語を僕も以前は良く使っていました。
しかし今はあまり使っていません。本来は、僕が最初に抱いていたもの
とは違う意味のようだからです。

  オライリーの「オープンソースソフトウェア」の中でLinus Torvalds
さんとAndrew Tanenbaumさんがマイクロカーネル対モノリシックなシス
テムをめぐって論争している部分があります。それを読むと、マイクロ
カーネルである条件は以下のようなものであると僕には思われました。

・マイクロカーネルにおける「カーネル」とは、カーネルモードで走る
  部分である。これはIA32で言うところの、CPL != 3の範囲であろう。
  この部分が極端に小さいことがマイクロカーネルである前提。

・マイクロカーネルシステムでは、たとえば、ファイルシステムやメモ
  リ管理などは、個別のプロセスとしてカーネルの外側で機能する。結
  局のところ、追い出せるべきものは全てカーネルの外に追い出してし
  まえという方針らしい。

  僕の作りたいOSASKは、確かに小さなカーネルで機能します。しかし
、ファイルシステムやメモリ管理のためにわざわざ別タスクを用意して
そこで処理しようとは思っていません。

  なんていうか、僕の「マイクロカーネル」のイメージは、タスクの乱
発であるように思われます。そんなのはいやです。いくらマルチタスク
制御に自信があるとは言っても、効率の観点から、そのようなシステム
は使いたくありません。

  僕のOSASKのソースはすでに多くのコードセグメントに別れていて、
それぞれがコマンドでやり取りするようになっています。つまり、それ
ぞれは十分に独立していて、一部を交換しても全体を再アセンブルする
必要はありません。これをLinus Torvaldsさんは「モジュール化」と呼
んでいるようなのでここでもそれにならうことにしますが、OSASKはモ
ジュール化には積極的です。僕はモジュール化が好きなんです。

  OSASKはDLLをカーネルと同じくらいに重要視しています。DLLはダイ
ナミックリンクライブラリーではなく、ダイナミックリンクカーネル
やダイナミックリンクデバイスドライバーだと思っていただいてもい
いくらいです。実際、呼び出し方法はシステムコールもDLLコールも同
じくfar-callで、セレクタが違うだけです。DLLはその設計によって、
CPL == 3で走るか、CPL == 0で走るかを選べます。ただし、CPL != 3
で走るためにはシェルにお伺いを立てる必要がありますが（笑）。CPL
 != 3で走る場合は、アプリから呼び出す際にコールゲートを通ること
になります。

  DLLの呼び出し方法とシステムコールの呼び出し方法に本質的な差が
ないというのは、見方によっては、システムコール体系をDLLによって
大幅に変更可能であるということを意味します。これにより、異なるシ
ステム向けに開発されているアプリケーションを、エミュレーションす
ることなく、同時に走らせることができるでしょう（もちろん、far-ca
llでシステムコールするわけではないシステムには化けられませんから
その場合はエミュレーターがぜひとも必要ですが）。これは、カーネル
やDLLの乗り換えが容易になることを意味していて、バージョンアップ
や開発競争を促進する効果があると考えています。システムが向上すれ
ば、アプリの開発もきっとやりやすくなることでしょう。

  ということで、モジュール化していくという点に関しては、なべちゃ
んさんと僕の方針は似ているようです。

>>  タスクを再開するのに必要な外部情報は、保存されます。そうでない
>>とタスクセーブの意義が無くなってしまいますから。
>とするとドライバはそれ用に作成されるということなんですね。
>バッファをユーザ側に持つのでしょうけど、
>（現状まで再現すべき）状態もそこに持たなければはいけないと。
>＃うーん何やら難しそうに感じてしまいます（苦笑）　＞ドライバ作成

  そんなことはないですよ、きっと。

  アプリが復元できない情報をドライバが保持すればいいだけです。た
とえばビデオドライバーなら、VRAMのイメージを持っておくとか。

  むしろマルチタスクに対応する方がタイミングまで絡んでくるので大
変でして、マルチタスク対応になってさえいれば、もう必要なものは保
存できているものですよ。

>>  これは、CSが指しているコードが書き換えられることを僕が毛嫌いし
>>ているせいです。コードは、コード中に埋め込まれているstaticな変数
>>も含めて、書き換え禁止です。
>私も嫌いなんですけど、なんというか実現方法が思いつかないんです。
>フルアセンブラならしごく簡単な話なのですが、
>Ｃ言語を考え出すと、自動変数という問題と
>スタティック変数とヒープメモリにある変数……これをどうやって
>配置すればいいのか（一緒にしてしまえばそれだけですが）。
>DS が不確定のときにどう読み出せばいいか（まぁOSの役目でしょうが）

  それは、DSを不確定にするな、と決め付ければそれで済むんじゃない
んですか？そうでなければ、アセンブラのassume文のようなものをC言
語に導入して、DSが使えない間、どのセグメントレジスタで代用するの
かを指示するとか・・・。

  結局、farポインタを使えばいいだけだと思います。ポインタを32bit
にするのではなく、48bitにするわけです。アセンブラじゃよくやるじ
ゃありませんか、メモリ転送ルーチンで「DS:ESIからのECXバイトをES:
EDIに転送する」みたいなのを。これは48bitポインタを使っているわけ
で、C言語もこれを認めればとりあえずマルチセグメントを使えるよう
にはなります。

>特に問題は自動変数なのですが……。
>私はスタックがメモリを食いつぶすしたり、
>そのこめに余計にスタックを獲得しておくのは大嫌いなのですか、
>セグメントを分けてしまうと、参照問題がいろいろと……。

  おっしゃりたいことはよく分かります。mallocさえしなければ、簡単
な解決方法があります。

  まず、staticな変数領域が16KB必要だとしましょう。これを、

    SS:0xffffc000 〜 SS:0x0ffffffff

に割り当てます。これは、起動時にコードから16KBを転送することで初
期化します（つまりコード内に初期値リストがある）。そして、起動時
のESPを0xffffc000にしておきます。そしてもちろんスタックセグメン
トは下方伸長型です。これで、スタックが不足したらページを追加して
リミットを上げてやればいいだけのことになります。これで、static変
数もauto変数も同一のセグメント上にあることになり、安泰です。

  問題はmallocです。mallocしたメモリをこのセグメント内に置くのは
困難です。スタックの下界より上を使ってしまうと、スタックが追いつ
いてmalloc領域に進入してくるかもしれませんし、かといってそれより
上方はスタックとstatic変数に完全に使われています。

>#ページングと上方伸長スタックセグメントを使えばなんとかなるか？

  結局、下方伸長型セグメントには期待しないで、適当に1MBほどのメ
モリを割りあえててその中に必要な分だけページを貼り付けるしかない
のでしょう。

>>それで、現在はスタートアップルーチンを埋め込んでいます。
>>このスタートアップルーチンはCSの内容をリードしてDSにコピーします。
>なるほど、たしかに問題なしですね。でもメモリが無駄に……。
>ん？　ページングテーブルの Write bit でやればなんとか
>なるのかな(^^;;

  いや、メモリは無駄になりますよ。もちろん、仮想記憶のおかげでア
クセスしない部分のメモリは使いませんが。でもこの方法は美しくはな
いです。無理矢理なんとかした、という感じです。まあ、C言語を使い
たい人がたくさんいる以上、現時点ではしょうがないです。


  それでは。

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