talosのカーネルは少々極端にモノリシックです。 いわゆるアプリケーションに含まれる機能の相当部分をカーネルに含んでいます。 このことにより概要で説明される幾つかの既存システムに対する決定的なメリットが自然に引き出されます。
talosでは各タスクは単純にプリエンプティブ/FCFSルール(優先度順、同一優先度の場合はリクエスト順)でスケジュールされます。 ただし、最低優先度タスク同士に限ってはラウンドロビンでスケジュールされます。 また、ユーザタスクは常に最低優先度です。
図はメモリマップ(リンク先は拡大図)。下が0で上がメモリ空間の上限。 配置はプロセッサのアーキテクチャ毎に違うがこれは特に配置に制限がない場合の配置例。
以下は各空間についての説明。
カーネル専用の空間。ユーザタスクからはアクセス不可
空間を割り当てればユーザタスクから読み書き可能。 プロセッサがサポートしていれば実行不可。 割り当てられていない空間はアクセス不可。 .dataと.bssに該当する空間は最初から割り当てられている。 が、実ページが割り当てられているとは限らない。
共有ライブラリのための空間。ユーザタスクからは書き込み不可。 共有ライブラリが読まれる度に下位方向へページ単位で成長し、回収はされない(予定)。
プロセス起動前にカーネルによって読み込まれる部分。 ユーザタスクからは書き込み不可。 この空間は同一の実行形式ファイル(LM)から起動される全てのプロセスで共有される。 LMにコードやデータのない部分はアクセス不可。
ヒープは取得も返却もO(1)なアルゴリズムで管理されます。 なのでリアルタイム的用途や割り込みハンドラ中でも安心して使えます。 もう少し具体的にはメモリ空間は2nバイト単位のサイズごとに設けられたPOOLで管理されます。 もしメモリ空間を取得しようとしてPOOLに十分な空き空間のブロックがない場合、メモリ空間は本来の意味でのヒープから取得されます。 なお、一旦切り出されたメモリ空間がヒープに戻されることはありません。
カーネル空間でもユーザ空間でもヒープは以上のように管理されます。 なお、これはメモリ空間管理の話なので、実ページの割り当てとは別の話です。
実行形式ファイル(LM)の形式は、おそらくelfになるだろうが形式そのものは未定。 共有ライブラリを指す部分は未定義シンボル。
仮想メモリ空間を用意する。 例えばIA32ならページディレクトリを用意し、カーネル領域と共有ライブラリの分をマスターデータから複製、プロセスクラスへ格納。 この段階ではユーザ空間は存在しないのでこれから作ろうとしてるプロセスのカーネルモードIPを次の段階を開始するよう設定し、この場は終了。
エラーなどの情報を収集するために現在のタスクはメッセージ待ちで待機。
プロセスが切り替わってくるとプロセス用のメモリ空間が有効になるので中身を用意する。 既に当該LMで動作しているプロセスがあればそのプロセスのページ定義を複製。 当該LMが読み込まれてなければROM空間(.textと.rodata)をメモリへマップするなり読み込むなりする。
未定義シンボルを共有ライブラリから検索し、なければ読み込み、未定義シンボルを解決する。
書き換え可能データ(.data)を読み込む)
未初期化データ(.bss)の分の空間を割り当てたらこの段階は終了。
ユーザモードスタックの空間を確保する。 LMに書いてあった実行開始アドレスへ*戻る*ようセットアップし、ユーザモードへ*戻る*。