tarosukeの日記： 俺OS xv あるいはtalos(仮

仮想メモリ管理の方針を決める。基本的にxivに書いた方法なのだが。
IA32用語のタスクはtalosにおいてはプロセスなので混乱せぬように。
talosではプロセス＝アドレス空間、タスク＝実行単位として使っている。

仮想メモリ
        プロセス空間にカーネルをまるごと出す事にする。GDTはそもそも
        カーネル空間そのものだし、ページテーブルの方もカーネルで使う
        テーブルをプロセスのページディレクトリに繋いで共用することで
        ページテーブル領域とその複製の処理を省略する。

        この辺はSHではページングしないエリアがあるのでそこにベクタな
        りカーネルを置くという設計に合わせたものでもある。

        ページャーは独立したプロセスで、IA32ではタスクゲートを用い
        て直接起動される。別プロセスにしないとスタック不足の時にシス
        テムごと死ぬし。またこのメカニズムを利用して、タスク起動時に
        はスタックの実ページは割り当てておかないという手抜きもでき
        る。当然仮想ページは確保するのだが。

スレッド管理
        talosではマルチスレッドが基本で、プロセスの中にタスクがごろ
        ごろ居る状況が普通になる予定なのだが、ユーザスレッドはやらな
        い。全てカーネルスレッドになる。

        理由は単純。メリットがない。talosではカーネルをプロセス空間
        上の共有メモリで直接アクセスするので、実際にタスクが切り替わ
        る時までプロセス切り替えは起きないからAPI発行のペナルティは
        ない。

        もし切り替え先のタスクが同一プロセスならTLBはフラッシュされ
        ないのでプロセス切り替えは全く起きないも同然だから別段ユーザ
        スレッドより重くなったりはしない。

        切り替え先のタスクが別プロセスならどちらにせよTLBがフラッシ
        ュされるのでこれもディスアドバンテージではない。なのでどっち
        でやっても同じ。ということになる。

        こういう状況があるのでユーザスレッドはやらない。SHではASID
        が変化してもTLBに相当するものがフラッシュされるようなことが
        ないのでもともとユーザスレッドにメリットは無い。

ファイル管理
        とある他の俺OSのコンセプトに刺激を受ける。ディスクキャッシュ
        が不要でキャッシュ-メモリ間転送も不要というのはなかなか旨そ
        うだ。だがそのまま持って来るわけでもなくて、talosのファイル
        は無名だったりする。ファイルシステムとしてはファイルはすべか
        らく番号で管理されるわけだ。

        このことであっちとは逆に「全部メモリ」になるわけだが、結局の
        ところ名前があるかどうかくらいの違いしかないだろう。ユーザは
        リンク名か書類自身が持っている名前を見る事になるのでファイル
        に名前がないからといってユーザが困る事もないし。

        このへんのユーザから見たファイルのコンセプトはBTRONに近いも
        のがあって、ファイルの削除可能条件が「誰からもリンクされてい
        ない事」だったりする。

        もっともBTRONの「屑実身」とは違い、そうなったファイルは「ゴ
        ミ箱」ファイルからリンクされるのでまだ消されていなければゴミ
        箱を漁る事もできる。なお必要になったら必要なだけ古いファイル
        が消えていくだけなので「ゴミ箱を空にする」操作は存在しない。

        ユーザから見るとかなりルーズなファイルシステムだわね。
        だれかさんの部屋のようだ。

# cervisiaがふっ飛んだのであんまりコーディングしたくないなぁ...
# さっさと鯖環境から作り直さないと。