(toppers-users 3449) Re: タスクスタックの状況を確認するためのシステムコール実現の御提案

[SHUKUGUCHI Masahiro]

コメントありがとうございます。

> (タスク例外の出自が"POSIXシグナルっぽいもの"への要求であるということに
> 間違いが無いとするならば，という仮定の基で，)そこを議論する必要，
> ありますかねぇ…．

すみません。議論を必要としない理由が判りません。

というか、既に議論していると思います。
CPU例外処理（CPU例外ハンドラの処理）は、μITRON4.0仕様ではあまり議論され
ていないという印象です。（どこまでCPUが発する例外に対応するか？という
問いに対して、”CPU例外”という事象に対応するユーザ定義のハンドラを登録
する手段を用意しますので、そのハンドラで処理してください。という枠組み
の提供をもって回答しているように見える）その点では、下記のコメントには
異論はありません。

> 結局，そのフラグを処理するのは，タスク例外処理ルーチンに移る前の
> カーネル内処理になるのかなと思います．ならば，上記のようなCPU例外に
> 任せることになります．タスク例外の枠組みで無理しない(ユーザに委ねる)
> ほうが，μITRON的な気がします．

また、タスクが発生した致命的CPU例外に対しての振舞いとしては、下記が
順当であることも了解します。

> ならば，シグナルハンドラ相当のタスク例外ではなく，カーネルレイヤに
> あるCPU例外に任せるのが順当なように思います．

ただ、それに至るまでの下記の

> ブロック不可能なシグナルが飛んだ時，有無を言わさず実行単位を殺すのは
> カーネルの仕事のはずです．

といった解釈や、ユーザ定義のCPU例外ハンドラはカーネルなのか？アプリケ
ーションの一部なのか？といった解釈や棲み分け・切り分けの議論がコミュニ
ティとして十分に共有されているかが疑問であり、議論されるべきと思います。

”レイヤ”が意図するところが作成者の分担（カーネルレイヤ＝カーネル開発
者が提供する）では無いと思いますし、CPU例外のハンドリングはシステムの
肝ですから、標準的なリアルタイムカーネルが提供できるものではないと思い
ます。

# 当たり前のことですが、標準的なRTOSを使うには、そこのところが解らない
# といけない。ということですね。

先のわたしのメールでは、CPU例外ハンドラはカーネルの一部ではないという
前提に立っていました。このため、CPU例外とタスク例外の2段構えを暗黙に想
定していたので中途半端な形であったと思います。

全般にわたしのメールの書き方に難があると思いつつも、このような議論は、
コンピュータシステムの進化や他のOSが提供するソリューションの進化ととも
に継続的に議論されてもよいと考えています。

Shukuguchi

MMU・MPUやCPU例外への対応如何が、今後のミドルレンジ以上の規模を持つ
システムへの適用の要件と直感的に思うんですね。（ミドルの細かい話は
置いておいてください。）

Masaki Muranaka <monamour ＠ monaka.org> wrote:
> こんにちは．
> 
> > （瑣末に）反論すると
> 
> 再帰的に瑣末反論するならば…
> 
> > そうなると、「タスクコンテキストで動作する」意義の議論が必要ですね。
> 
> (タスク例外の出自が"POSIXシグナルっぽいもの"への要求であるということに
> 間違いが無いとするならば，という仮定の基で，)そこを議論する必要，
> ありますかねぇ…．
> POSIXシグナルっぽくないところという線で検討の余地があるとしたら，
> ブロック不可能なシグナルの扱いかなという気がします．
> ブロック不可能なシグナルが飛んだ時，有無を言わさず実行単位を殺すのは
> カーネルの仕事のはずです．
> ならば，シグナルハンドラ相当のタスク例外ではなく，カーネルレイヤに
> あるCPU例外に任せるのが順当なように思います．
> 
> タスク例外にマスク不可能なフラグを付けるという方針は有り得ますけれど，
> 結局，そのフラグを処理するのは，タスク例外処理ルーチンに移る前の
> カーネル内処理になるのかなと思います．ならば，上記のようなCPU例外に
> 任せることになります．タスク例外の枠組みで無理しない(ユーザに委ねる)
> ほうが，μITRON的な気がします．
> // 直感です．
> 
> 2011年5月1日15:19 SHUKUGUCHI Masahiro <shukuguchi ＠ biz.nifty.jp>:
> > コメントありがとうございます。
> >
> > 動的検出方法をハードウェアまたはRTOS以外の責務にすることに依存はあり
> > ません。しかし、規模（開発、予算等）や用途（要求される安全性等）によ
> > り、それが適わぬこともあります。その点で、検討した際のソリューション
> > として、これらの議論がなされていてもよいと思います。
> >
> > （瑣末に）反論すると
> >> しかし，タスク例外はタスクコンテキストで実行されますので，スタックが
> >> 溢れるかもという時に使うのは危険かもしれません．
> > であれば、スタックオーバーフォロー寸前でのタスク例外処理ルーチンが呼び
> > 出されるシチュエーションは考慮すべきことですので、実装としてタスク例外
> > 処理ルーチンのスタックを別に確保して安全性を高める方式はあると思います。
> >
> > そうなると、「タスクコンテキストで動作する」意義の議論が必要ですね。
> >
> > さて、一方
> >> そうでない場合もソフトウェア割込みなど使って非タスクコンテキストに
> >> 移すほうが，より安全ではないでしょうか．標準化もしやすそうですし．
> >
> > はい。仰せのとおりです。
> > 先のメールの議論を読み返せば、途中を端折っているところがありますね。
> > CPU（および付随するハードウェア）または非タスクコンテキストでの検出が
> > 前提で、そこからCPU例外ハンドラの起動に持っていくことを暗黙としていま
> > した。
> >
> >
> >> で，こういった案をどういうふうにフィードバックするのがよいのか
> >> ということについてですが…
> >
> > はい。本題はこちらです。
> >
> > 実現というか問題解決のドメインとしては、、、
> >
> >> いずれの案にせよ，タスクスタックを扱う必要がありますので，
> >> SILでカバーするのは難しいのではと思います．
> >> 非タスクコンテキストについては SIL でイケるかもしれませんけれども．
> >
> > 現状カーネルとSILとの関連、切り分けの問題ですが、実装主体には乱暴に
> > カーネルとSILとの通信手段を決めておくのも手かと思います。
> >
> >> とはいえ，カーネル仕様にできるかというと難しい気もします．
> >> ガイドラインとかイディオムとか定石とかいう感じの文書になるの
> >> かなと思います．
> >
> > カーネルAPI仕様の範疇か否かという観点では難しいですが、カーネルの責務
> > をどのように捉えるか？で変わってくるようにも思います。
> >
> > しかし、現実解としては
> >> ガイドラインとかイディオムとか定石とかいう感じの文書になるの
> >> かなと思います．
> >
> > というところですね。
> >
> > # 藤倉さんへの返信に続く。
> >
> > Shukuguchi
> >
> >> こんにちは．
> >>
> >> 動的検出の方法は，ハードウェアに頼るか，GCC の -fstack-protector のような
> >> ものを使うか，…いずれにしてもRTOS以外の何かにやらせたほうがよいでしょう．
> >> (手埋めだと網羅確保の問題もありますし)
> >>
> >>
> >> 発生時のカーネルの対応についてですが，POSIXシグナルとの類似性から，
> >> タスク例外処理を使いたくなる気持ちは分かります．
> >> しかし，タスク例外はタスクコンテキストで実行されますので，スタックが
> >> 溢れるかもという時に使うのは危険かもしれません．
> >>
> >> ハードウェアの支援がある場合にはCPU例外が発生するでしょう．
> >> そうでない場合もソフトウェア割込みなど使って非タスクコンテキストに
> >> 移すほうが，より安全ではないでしょうか．標準化もしやすそうですし．
> >> (非タスクコンテキスト内でタスクスタックの残量を見てから
> >> iras_tex を呼ぶ，というパターンはアリでしょう．)
> >>
> >> スタックの残量は，バイト数で得られれば十分ではないでしょうか．
> >> スタック用の配列の先頭番地/サイズとスタックポインタのアドレスは
> >> 現在TOPPERSが対応しているアーキテクチャなら解りますよね．
> >> スタック残量が僅少のときに関数を安全に呼べるかどうかは
> >> アーキテクチャ(もしくはABIが規定するアラインメント)依存ですが，
> >> 類似の問題はメモリプールでも起き得ますので，アプリ開発者の
> >> 解釈に委ねるとしてもよいはずです．
> >>
> >>
> >> で，こういった案をどういうふうにフィードバックするのがよいのか
> >> ということについてですが…
> >>
> >> いずれの案にせよ，タスクスタックを扱う必要がありますので，
> >> SILでカバーするのは難しいのではと思います．
> >> 非タスクコンテキストについては SIL でイケるかもしれませんけれども．
> >>
> >> とはいえ，カーネル仕様にできるかというと難しい気もします．
> >> ガイドラインとかイディオムとか定石とかいう感じの文書になるの
> >> かなと思います．
> >>
> >>
> >> 2011年4月26日22:59 SHUKUGUCHI Masahiro <shukuguchi ＠ biz.nifty.jp>:
> >> > 宿口です。
> >> >
> >> > 有益なアイデアだと思うのですが、意外と冷たい（？）反応でしたね。
> >> >
> >> > 静的に、タスク設計時のスタック見積りは原則だと思います。
> >> >
> >> > 動的な防護策として、ディスパッチャ、システムサービスのエントリや割込み
> >> > 処理の入口でのスタックチェックがあると良いと思います。これの課題（？）
> >> > は、処理速度とスタックオーバフローを検出した場合の振舞いの定義ですかね。
> >> >
> >> > 処理速度は、コンパイルスイッチ等でスタックチェックの有効・無効を選択
> >> > できれば問題は少なくなりそうですが、それだと、動的にチェックする動機が
> >> > 薄れます。（信用の置けないアプリケーションを搭載するような場合だと特に）
> >> >
> >> > スタックオーバフロー検出時のカーネルの振舞いは、μITRON仕様の範囲では決
> >> > めようが無いと思いますが、タスク例外処理の起動あたりが妥当と思います。
> >> > しかし、タスク例外処理の起動はマスクできますし、そもそもタスク例外処理
> >> > ルーチンが定義されていないと意味を成さないですね。
> >> >
> >> > また、カーネルで一意に振舞いを決めたくなりますが、カーネルに過度の機能
> >> > を持たせることの懸念が生じるように思います。
> >> >
> >> > # だんだんネガティブになっていく。。。
> >> >
> >> > 一方、
> >> > タスク観点では、タスク例外処理ルーチンでスタックオーバーフローを検出した
> >> > 場合に状況を知りたくなりますので、その際や、デバッグ時にはスタック状況を
> >> > 確認するインタフェースは有効だと思います。
> >> >
> >> > でも、CPUアーキテクチャに依存しますので、カーネルよりはSILあたりの
> >> > 実装になりますか・・・ スタックの情報以外にカーネル等の資源状況を調査
> >> > できるデバッギングパッケージなるものがあると、うれしいかもしれませんね。
> >> >
> >> > とりとめもなくすみません。
> >> >
> >> > Shukuguchi
> >> >
> >> >> 皆様
> >> >>
> >> >> 先日は多くの有用なアイデアの共有ありがとうございました。
> >> >>
> >> >> TOPPERSとしては今のところ「それはTOPPERSのサービスとして提供するものではない。」という認識に至りました。
> >> >> このような機能については、先日高田先生から御指摘いただいたTECSを使って実装すれば良いのかもしれませんね。
> >> >>
> >> >> 中村晋一郎
> >> >
> >> >
> >> >
> >
> >
> >