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

[OSASK 1535] Re: memory management.

  こんにちは、川合です。


nabe さんは 2001/02/23 01:10:40 の「[OSASK 1532] Re: memory mana
gement.」で書きました：

>>  結局、どのタスクとどのタスクを繋ぐかは、シェルの仕事なのです。
>>必要なら、繋ぎかえもやります。
>マルチスレッドやモジュール分割をしたいアプリは、
>特定の相手につなぎたいと思うことがあるのではないかと思うのですが。
>そこら辺の保証はシェルに一任される、と。

  全くそのとおりです。

>基本的にはどうやって特定させようとお考えですか？

  アプリには、新たにタスクを作ることができます（もちろん無尽蔵に
作れるわけではなくてシェル次第なのですが）。で、自分が作ったタス
クについては自分に繋ぐこともできますし、子タスク同志を繋いでやる
こともでるようにしようと思っています。

  この仕組みは以下のようになります。

  OSASKにはスロットという概念があり、これによってタスクなどを特
定します。

  一般のウィンドウライブラリーがどのような構成になっているのか僕
はよく知らないのですが、おそらく、ウィンドウをオープンするための
関数を呼ぶとどこかにウィンドウ構造体が用意されて、そのポインタを
ハンドルとしてアプリに返し、以後はそのハンドルを使ってウィンドウ
を指定するものだと思います。・・・DOSのファイルシステムはこんな
感じですね。

  以前から、僕はこの方法には問題があると考えていました。

  まず、アプリがバグなどでハンドルを間違えたらどうなるんでしょう
か？間違えなければいいといわれればそれまでですが、ハンドルを間違
えたせいでシステムがかき乱されるのは僕はいやです。

  これに対処するには、いくつかの方法があります。

・ウィンドウ構造体の中にシグネチャーストリング（チェック用のバイ
  ト列）を入れておき、それを毎回確認する。

・システム側で発行したハンドルの一覧をテーブルとして持っておき、
  アプリが指定したハンドルが発行したものであるかを毎回確認する。

  この両者をともに行うこともできるでしょう。しかし僕はこのどちら
も気に入りませんでした。それで、もう一つ、新しい方法を考えたので
す。それがスロットです。

  スロットはシステム内にあるスロットテーブルへのポインタです。ス
ロットテーブルは16バイトで構成されるスロットブロックの配列で、イ
メージとしてはLDTのようなものです。この中に、システム内のポイン
タ（ハンドル）やそのハンドルがどの種類のものであるかなどが書き込
まれています。これはもちろん、タスクごとに独立に用意されています
。

  アプリはウィンドウをオープンする時に、ハンドルを受け取るのでは
なく、スロット番号を指定します。そうするとシステムはウィンドウ構
造体をシステム内に用意し、そのポインタを指定されたスロットブロッ
クに書き込みます。そしてそのウィンドウに対してアクセスする際は、
全てこのスロット番号を指定することでウィンドウを指定します。

  もちろん、このスロットテーブルはアプリからはアクセスできません
。ライトが許されないのはもちろんですが、リードも許しません。シス
テムの微妙な様子を知ることは仮想化への思想に反するからです。

  それでタスクの話ですが、タスクをオープンする場合もスロットを指
定します。結局、アプリはスロットにないものはどうやってもアクセス
できません。もしかしたらアプリにバグがあってスロット番号を間違え
てしまうかもしれません。でも、それによっておかしくなるのはそのア
プリからアクセスできる範囲だけに限られます。

  スロットにはもう一つの効用があります。これは、スロットブロック
内のポインタをシステムが必要に応じて変更しても、アプリには全く検
知できないということです。これが、接続するタスクを必要に応じて繋
ぎかえられる、という発言の意味です。OSがセグメントベースを変更し
てもアプリには分からない、というのと全く同じ事です。これは、タス
クに限らず、スロットで管理される全てのリソースについて言えます。
そしてOSASKは全てのリソースをスロットで管理する予定です。

  このスロットについては、すでに機能しています。guide06にも頻繁
にスロットという語が出ています。

>>  基本的には、他のアプリの領域にアクセスする、というものです。た
>>だしネットワークごしになっている場合は、システムが裏方でコピーし
>>ます。
>アクセスはリードオンリー？　それとも専用のセレクタを作成しますか？
>そしてないと他のアプリに破壊されてしまう危険性が生まれるような……。

  それはアプリの設計次第です。リードオンリーでもいいでしょう。専
用のセレクタを作ってもいいでしょう。C言語でセグメントレスなプロ
グラミングを好む人となら、リードもライトも可にしたいというかもし
れません。

  他のアプリに破壊される可能性を示唆していますが、それは確かにあ
りえます。ここでいう「他のアプリ」というのは通信相手のことであっ
て、なんの関係もない他人ではありません。なんの関係もないアプリは
リードもライトもできませんから。

  通信相手に破壊されるのが恐いなら、リードオンリーにすればいいで
しょう。通信相手が信用できるなら、ライトも許せばいいでしょう。こ
れは純粋にアプリを書くプログラマーのプログラミングスタイルの問題
です。

  OSASKは徹底的な仮想化と安全性を追求する一方で、スキルのあるプ
ログラマーにもどかしさを感じさせないという理想も追求しています。
多分なべちゃんさんだったと思いますが、かつて、OSASKはアプリから
のI/O直叩きを許してくれるのか？と質問されました。僕はその時、「
許す」と答えました。つまり、I/O直叩きするようなアプリも、シェル
が許せば走っていいわけです。

  「シェルが許せば」という表現を僕はよく使いますが、「シェルが許
す」ということは、つまり「ユーザーが許す」ということです。シェル
はユーザーよりも偉いわけではありません。一番偉いのはユーザーです
。シェルはユーザーの意志をシステムに反映させる義務を負っており、
そのシェルの手助けをするのがカーネルやドライバーなのです。だから
ユーザーがI/O直叩きを許すようなアプリを書いて、それを実行したい
と思っているのに、シェルが実行許可を与えることができないようなら
、それは不良品のシェルです。

  僕はスロットがどうのこうのと書きましたが、こんなプログラミング
スタイルは受け入れられないというプログラマーがいるかもしれません
。その場合、スロットを使わないプログラミングをしてもいいでしょう
。そのためのシステムコール体系を用意し、シェルがそれを許せばいい
だけです。僕は自分の気に入らないものには「川合秀実推奨」を出しま
せんが、存在を否定することはしません。僕が常に正しいとは限らない
んですから。

  それで、I/O直叩きすら許すようなOSが、タスク間通信のための共有
メモリのライトアクセス権設定を許さないはずがないじゃないですか（
笑）。


  それでは。

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