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

[Masaki Muranaka]

こんにちは．

> 無理解の産物（すなわち間違い）である。

とまで強くは思いません．直感としてタスク例外は
タスクコンテキストで動作させるほうが仕様として自然に思える
という程度です．
TOPPERSの実装上も，ここを変えると面倒かなと思います．
自タスクがタスク例外を発行したときに，関数呼び出しで
タスク例外ハンドラを呼ぶケースがあるように記憶していますので．


CPU例外に任せる方針案は既に書きましたが，POSIXシグナルと等価な
機能セットを志向するならば，代替シグナルスタックに相当するものを
用意するという方針案も有り得るはずですね．(個人的に支持するかは
さておきですけれども)
この場合でも，実行コンテキストはタスクコンテキストとするのが
自然かと思います．APIが要りますし，カーネルにも手を入れる必要が
でてきますので，仕様化が求められることにはなるでしょうね．



2011年5月5日4:36 SHUKUGUCHI Masahiro <shukuguchi ＠ biz.nifty.jp>:
> コメントありがとうございます。
>
> まず、議論の土台として
>
>> > というか、既に議論していると思います。
>>
>> ?
>
> や
>
>> POSIXシグナルのはハンドラが(カーネルでなく)プロセス/スレッドのコンテキストで
>> 動くことを踏まえると，『「タスクコンテキストで動作する」意義の議論』を
>> 行うべき理由が私には見つけられません．
>
> のようなコメントをいただいていることが、がわたしの主観として、議論”で
> あると考えています。
>
> その上で
>
>> 仕様におけるCPU例外の曖昧さや，他のOSと比較した時のアプリ/カーネルの
>> 曖昧さはそれはそれとしてあるかもしれません．
>> POSIXシグナルには存在する"マスク不可能なシグナル"に相当するものが
>> タスク例外にはない，という仕様上の非対称性もあるやもしれません．
>> しかしそれらとタスク例外の実行コンテキストの話題とは，クリスプに
>> 分けられるでしょう．
>
> こういった見解をいただけることは大変うれしく思います。
>
> CPU例外の仕様と実装に近いタスク例外の実行コンテキストの議論が別口で
> あることは了解しますが、それと議論の要不要の関係性には理解が及びませ
> ん。ただ、4.0仕様は、実装を意識したところがあると思うので、コンテキス
> トの話は必須かなと思うわけです。
>
> で、議論の要不要でなく
>
> ”タスク例外が"POSIXシグナルっぽいもの"を目指したもの”であるから
> 「タスク例外処理ルーチンの実行コンテキストは所属するタスクのコンテ
> 　キストであることが自然であり、また、それが必要である」
> ゆえに、CPU例外処理や実装の都合でその仕様を乱すような『「タスク例外
> 処理ルーチンがタスクコンテキストで動作する」意義の議論』は無理解の
> 産物（すなわち間違い）である。
>
> と言ってもらったほうが判り易いですね。
>
> ずっと、そのように仰せだったのでしょうけれど、わたしが議論の枠組みの
> 観点と仕様・実装の観点を行き来してしまったのでご面倒をおかけしました。
>
> ご指導ありがとうございました。
>
> Shukuguchi
>
>> おはようございます．
>>
>> >> (タスク例外の出自が"POSIXシグナルっぽいもの"への要求であるということに
>> >> 間違いが無いとするならば，という仮定の基で，)そこを議論する必要，
>> >> ありますかねぇ…．
>> >
>> > すみません。議論を必要としない理由が判りません。
>> >
>> > というか、既に議論していると思います。
>>
>> ?
>> タスク例外が"POSIXシグナルっぽいもの"を目指したものであるとして，
>> POSIXシグナルのはハンドラが(カーネルでなく)プロセス/スレッドのコンテキストで
>> 動くことを踏まえると，『「タスクコンテキストで動作する」意義の議論』を
>> 行うべき理由が私には見つけられません．
>>
>> 仕様におけるCPU例外の曖昧さや，他のOSと比較した時のアプリ/カーネルの
>> 曖昧さはそれはそれとしてあるかもしれません．
>> POSIXシグナルには存在する"マスク不可能なシグナル"に相当するものが
>> タスク例外にはない，という仕様上の非対称性もあるやもしれません．
>> しかしそれらとタスク例外の実行コンテキストの話題とは，クリスプに
>> 分けられるでしょう．
>>
>>
>> いや敢えて過去を清算して仕様を混ぜっかえす自由を新世代カーネル以降の
>> TOPPERSは手に入れているわけですが，上記に関して言えば，その価値が
>> あるようには私には思えなかったりします．(今のところ)
>>
>>
>> 2011年5月5日3:03 SHUKUGUCHI Masahiro <shukuguchi ＠ biz.nifty.jp>:
>> > コメントありがとうございます。
>> >
>> >> (タスク例外の出自が"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を使って実装すれば良いのかもしれませんね。
>> >> >> >>
>> >> >> >> 中村晋一郎
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >> >
>> >
>> >
>> >
>
>
>