μITRON (TOPPERS)系OSの保護ドメインをざっくりと理解する.

H2Bロケットの制御で実用になり,最近ではETロボコン方面でも話題になる,μITRON4.0/PX由来のアクセス保護機能. 独自の仕様の割に,平易な解説文章がないという不満の声を聞いたので,連ツイでお茶を濁しました.
7

[連ツイに入る前に] 仕様の歴史と区別について.

μITRON系のTOPPERSの保護機能は,トロン協会がまとめていたμITRON4.0/PX仕様がベースになっています.
TOPPERSでは,PX仕様からいくつかの機能変更をおこなった,JSPカーネルベースのHRPカーネルがまず作られました.
その後,ASPカーネルベースのHRP2カーネルが作られています.

本まとめでは,PX仕様/HRPカーネル/HRP2カーネル は,あまり厳密には区別していません.概要説明ですから.

連ツイの背景

もなか @monamour555

TOPPERS/HRPカーネルの保護ドメインは,わかってしまえば簡単なのだけれども,大抵のエンジニアが慣れ親しんでいるPOSIXやWin32のプロセスモデルとは違うので,最初はとっつきづらい.

2015-05-25 09:32:08
もなか @monamour555

μITRON/PX 由来のアレコレは,解説文書なく仕様書だけで理解するのは(無理ではないだろうけれど)ちょっとつらいはず.で,昔,Interface誌に解説を書いた…気がしていたのだけれど,見つからない.あれ,ボツになったんだっけか?

2015-05-25 09:34:15
もなか @monamour555

(保護ドメインの概念が解らなくても,カーネルドメインにすべて記述すれば普通のμITRON …TOPPERS 第2世代なら ASP… カーネルとして使えるので. 実質無問題ではある)

2015-05-25 09:43:22
もなか @monamour555

うーん.なんでボツになったのだっけか.連載が終わっちゃったからかなとか一瞬思ったのだけれど,時期的に整合しない.なんかの雑談で「じゃあ書きましょうか?」 とかいって下書きだけしてお蔵入りとかなら,まま,ありそげではある.

2015-05-25 10:17:34

保護機能は2つの要素から成る

もなか @monamour555

web日記に書くと技術的に折り目正しくしないといけないから,ラフなツイートでお茶を濁す. まあたぶん,TOPPERSの保護ドメインが難しいと感じる最大の理由は,2つの要素から成り立っているということを図示していないこと. 図が無いのはTOPPERSの"伝統"なので諦めるしか無い.

2015-05-25 10:20:53

処理単位と保護ドメイン

もなか @monamour555

保護ドメインの要素の1つ目は,処理単位に関するもの.タスクとかハンドラとか.これらは現在的なOSのプロセスとスレッドの関係と近い.保護ドメインという名の,死なないプロセスみたいなものに処理単位が束縛される.スタックは厳密にはメモリなのだけれど,処理単位のリソースとして扱われる.

2015-05-25 10:27:36
もなか @monamour555

ある処理単位の実行中は,その処理単位が所属する以外の保護ドメインの諸々が置かれているメモリ領域の読み書きが禁止される.そんなふうに考えておけば概ねOK.POSIXプロセスっぽい. 例外はカーネルドメインで,これに所属する処理単位の実行中は,メモリ保護なしの古き良きRTOSとなる.

2015-05-25 10:37:24
もなか @monamour555

以上,処理単位の保護ドメイン.現在的なOSが持つ1タスク-nスレッドモデルを理解しているなら,まあちょっとキモいと感じるかもしれんけど理解できると思う. で,なんの解説文書もない状態では,理解に苦しむであろうアクセス許可ベクタ.これが,保護ドメインの要素の2つ目.

2015-05-25 10:43:05

カーネルオブジェクトと保護ドメイン

ざっくり言うと,ファイルシステムみたいなアクセス制御モデルです.

もなか @monamour555

μITRON由来OSのAPIは,ほぼすべて同期通信機能である.つまり,送信者と受信者が居る.これを意識できるかどうかが,アクセス許可ベクタのキモ. そして,たぶん送信タスクと受信タスクは違う保護ドメインに置きたくなったりするよなー,って想像できたなら,もう全貌は理解できている.

2015-05-25 10:45:49
もなか @monamour555

μITRON4.0/PX由来のドメインモデルでは,基本的にすべてのカーネルオブジェクトは保護ドメインの所有物ではない.全オブジェクトはカーネルの所有物である.ここに合点できるかどうかが重要. (処理単位とかメモリとかでグダっている部分はあるのだけれどそれはひとまず目をそらして).

2015-05-25 10:51:35
もなか @monamour555

そして,μITRON仕様由来の各カーネルオブジェクトにアクセスする処理(API)は,それぞれ概ね「送信」「受信」「管理」「参照」の4つに概ね分けられるっていう気づきが重要.sig_sem / wai_sem / del_sem / ref_sem みたいに.

2015-05-25 11:00:14
もなか @monamour555

これら前提が揃うと,アクセス許可ベクタの話ができる.APIの呼び出し側は処理単位なのだから,なんらか保護ドメインに所属している.カーネルは,APIの呼び出され時に,その呼び出しが4つの処理種別に応じてアクセス許可ベクタを参照し,呼び出しの許可/不許可を決定する.

2015-05-25 11:07:01
もなか @monamour555

「アクセス許可ベクタは,ファイルシステムのアクセスパーミッションみたいなものだ」と思えば,だいたい合っている. ファイルシステムの場合,オーナーとかグループとかあるので,厳密には違うのだけれど. 0755 みたいなビットマップになっているという点については同じ.

2015-05-25 11:09:53

雑感

もなか @monamour555

って,ざっくり解説でも結構な量の連ツイになっちゃう技術を,EV3のユーザ層にぽいって投げちゃうのって,おいおい随分な無理ゲーだなって思うのだけれどもなぁ. NCESは非常に優秀な方々が粒ぞろいでありますゆえ,無理ゲーだと認識していないのでありませう.なむ.

2015-05-25 11:15:19
もなか @monamour555

余談なのだけれど,μITRON/PX由来のアクセス許可ベクタって,カーネルオブジェクトの動的生成が無いなら,静的解析でエラーチェックできるよぬ. PXのときはRLLが後ろに控えていたから,動的チェックに妥当性あったとは思うのだけれど.

2015-05-25 11:57:23

まとめ

中の人たちが優秀すぎて完結してしまい(または国際競争に忙しすぎて外のことなど構えず),出元の情報量 K に対し,距離 r だけ離れると情報量 K' = K / r^2 しか得られない,というのが TOPPERS の現状です.
わからないことがあるときは,コミュニティに参加して,出元からの距離 r を小さくする努力をしましょう.
(私は既にコミュニティの中の人ではありませんのでお手伝いはできません.)