【TOPPERS】ITRON総合スレ3【NORTi】【HOS】 (880ﾚｽ)
上下前次1-新
596: ITRON名無しさん ◆4WD27e3i1o 2010/11/01(月)11:08 AAS
>>593
誰しも，チラシの裏に書き捨てたいことの一つや二つはありますし，
壷やらヒwiヒヒerやらMLやらリアルやら上手に使い分ければと．
597: ITRON名無しさん ◆4WD27e3i1o 2010/11/01(月)11:20 AAS
>>594
> 「ターゲット依存」は前者かな．
s/依存/定義/
母語が仕様書の >>581 に怒られそうだ．
蛇足ついでに．
「ターゲット定義」はRelease 1.2.0仕様書だと 2.1.2 で定義されているね．
ターゲット非依存としている場合でも逸脱を明示すればターゲット毎に制約が許される場合もある．
詳しくは原本を読んでみてね．
598(1): 2010/11/01(月)12:47 AAS
>594
よくわかった。
>>▼μITRON4.0仕様の「実装定義」は「ターゲット定義」と読み替え，修正する．▲
というのはμITRON4.0仕様書を修正せよ という話ではなく、実装仕様書を書き起こす際、μITRON4.0仕様書をコピペしたものから、s/「実装定義」/「ターゲット定義」/g せよ という話なんですね。誤解していました。
さて、本題に戻りますが、
>TMIN_INTPRIを固定するか設定できるようにするか，設定できるようにする場合の設定方法は，ターゲット定義である．
ということは、
TMIN_INTPRIを固定するか設定できるようにするか，設定できるようにする場合の設定方法は，ターゲット毎に用意するドキュメントにおいて規定されている。
に置き換えられる。
省9
599: 2010/11/01(月)13:01 AAS
>>594
>未定義の用語があるのは，まだ網羅性に余地があるというのもあるね．
>読者の技術知識やカーネルが提供する機能を考えれば自明だから省略しているというのもあるよ．
>「ターゲット依存」は前者かな．「メモリ保護」は後者ではないかな．
メモリ保護は自明というのは、たぶん関係者ではそうなんだと思いますが、だから抜けている
のでしょう。
2.3.2 メモリオブジェクトのアクセス保護
というのがあり、これをメモリ保護と呼んでおらず、「メモリオブジェクトのアクセス保護」と
「メモリ保護」と乱用しているのですよ。
ドキュメントの査読が不十分なんだと思いますが
600(1): ITRON名無しさん ◆4WD27e3i1o 2010/11/01(月)15:28 AAS
>>598
> ターゲット定義だからどうした？ って話だと思うが。
その件に関してだけいえば，統合仕様書を引き合いに出すのは冗長だよ，という話でもあるよね．
正直，全ての情報を精査したわけではないけれど，>>598 の言うとおりなら，
ターゲット定義を記述した文書の誤りか，実装の誤りということだろうね．
601(3): 2010/11/01(月)16:31 AAS
ここに少しありますね。
外部ﾘﾝｸ[pdf]:www.kumikomi.net
自分は、ASPはカーネル管理外を使えるようにしたものであるという
うたい文句のひとつだったと思っている。上記PDFでも紹介されている。
これがターゲット定義だから出来ていないのは、個別の問題という
のはあまりに言い訳がましいと思っている。
なぜカーネル管理外がどうこう言うのは、
TOPPERSのカーネルが多少手を抜いた部分がネックになるので
その分、カーネル管理外を用意する必要があると思うからです。
なんのことかわからないかもしれませんが、優先度待ちキューの
省6
602(2): ITRON名無しさん ◆4WD27e3i1o 2010/11/01(月)21:50 AAS
>>601
ああそのプレゼンの筆者をぼくはよく知っているよ．でも，そのプレゼンも統合仕様書も，ガンガッて使えるようにしたとは書いてないよね．
書くはず無いんだよね．
一般論としして，リソースを統べるカーネルの仕様を決める人たちが，管理できない領域のカーネル管理外を積極的に勧めたとしたら，構造的に頭オカシイよね．
ただ，4.0仕様以前のμITRONを含むもう一つのITRON仕様よりは，問題に向かい合おうとしている．>>601は，どう感じているかな．
優先度待ちキューの問題は…カーネル管理外で解決できる問題とは思えないよ．一般論としてはね．
もちろん，ぼくが知らないアーキテクチャで上手くいくレアケースの可能性について，否定はしないよ．
603: ITRON名無しさん ◆4WD27e3i1o 2010/11/01(月)22:22 AAS
>>559
PX仕様だけで言うならば，色々と検討が足りなかったことが明らかになっているね．
IIMP→HRP→HRP2でAPIの変更なんていう大変更も加わっているよね．
当時の査読がどうだったかという問題もあるだろうけれど，
T-KernelとTOPPERSの分断とか，(今は亡き)TRON協会の対応とか，さまざまな要因で，
関係者が改訂したくても改訂できないという状況が続いてしまったという，ツマラナイ事情もあるんだよ．
この辺りは問題の性質上，表には見えてこないよね．
ぼくも，今の年齢で言えば50代以上の大御所連中には，いろいろ言いたいこともあるけれど，詮ないから言わない．ヘタレでごめんね．
604: ITRON名無しさん ◆4WD27e3i1o 2010/11/01(月)22:23 AAS
あ，HRP2はまだ内輪ネタだった．ごめん．
605(1): 2010/11/02(火)11:43 AAS
いくつもコメントするのも何なので、ケース別に番号つけます。
1.カーネル管理外について
>602
>一般論としして，リソースを統べるカーネルの仕様を決める人たちが，管理できない領域のカーネル管理外
>を積極的に勧めたとしたら，構造的に頭オカシイよね．
>ただ，4.0仕様以前のμITRONを含むもう一つのITRON仕様よりは，問題に向かい合おうとしている．>>601は，
>どう感じているかな．
リソースを統べるカーネルという意識は私にはない。だからITRONごときがリソースを占有するな
という思いがある。そういう意味でカーネル管理外は重要な機能だと考えています。
2.優先度待ちキューの問題
省10
606(1): 2010/11/02(火)12:32 AAS
ついでに書いておきますが、PXについては、セキュアOS的なもの
ではない仕様なんですよね。
unixでいうところの chmod が誰でもできちゃう仕様のようですが
IIMP→HRP→HRP2とかで対応されたりしているのでしょうか。
607(1): ITRON名無しさん ◆4WD27e3i1o 2010/11/02(火)16:41 AAS
> リソースを統べるカーネルという意識は私にはない。
きみがそう思うことは止めないけれど．
>>601 のプレゼンの人は，カーネルの仕事は仮想機械の提供であるという立ち位置だよ．
最近の筆である組込みプレスの仮想化特集でも立ち位置を崩していない．
必要悪としてのカーネル管理外割込みを否定はしないだろうけれどもね．
きみの主張を裏付ける参考引用としては不適切ではないかな．
608: ITRON名無しさん ◆4WD27e3i1o 2010/11/02(火)17:06 AAS
>>605-606
> 明らかになっている情報源が開示可能なら教えて欲しいです。（まじめに）
残念ながら，ことごとくpublicでないんだよね…．使われる分野が分野だけに，いろいろ難しいの…．
本当に急いでいるのであれば，TOPPPERSの個人会員(準会員で十分)になって，先月の技術検討会議の資料を取り寄せることを勧めるかな．
急ぎでなければ，HRP2カーネルのリリースは年内…遅くとも年度内にあるかなと思う．
その時に統合仕様書も改定になるだろうから，PX仕様と差分を取ればいろいろ見えてくると思うよ．
ちなみに，PX から HRP2 に到るまで，ファイルシステムは無いし chmod も無いよ．
アクセス許可ベクタがアクセスパーミッションという意味では似ているけれど，非なるものと思ったほうが良いかもね．
アクセス許可ベクタの変更は，動的生成をサポートしていなければできないし，できたとしてもカーネルドメインのみに絞ることは容易なので，誰でも変更できるというのには当たらないと思うよ．
ただ，PX系の仕様は，アプリ開発者の過失によるダメージを最小限にするということが主目的で，悪意あるアプリケーションの混入と攻撃についてはあまり重視されていない．っていう傾向はあるよ．
省2
609: 2010/11/02(火)18:24 AAS
dispacherの汗がトリッキーなことしてるのが
610: 2010/11/02(火)19:59 AAS
>607
私の頭が悪いのかもしれませんが。貴殿の文学的表現がよくわからないです。
仮想機械の提供だから、CPUを占有してもよい ということ？
>組込みプレスの仮想化特集
については読んでいないので、わからないですね。
ただ、自分が思うのは、ITRONが組込みシステムの基盤になっているとは思えない
ことがあるんじゃないかと思える状況として以下の２点あるように思う。
ひとつは結構な規模のシステムでITRONを使っているシステムでは、アプリケーション層
が結構な規模らしいが下位層のITRONはラッピングをしていて、マイコンやOSが変わっても
対応できるようにしている。 ありふれた方式かもしれないが、ITRONである必要は
省11
611: ITRON名無しさん ◆4WD27e3i1o 2010/11/02(火)20:24 AAS
> 新機能としてうたい文句
リアルで彼に聞けばよいと思うよ．
彼でなくても，TOPPERSの中の人は非実在ではないから，会う気になれば会えるよ．来月はETだしね．
612(1): 2010/11/02(火)21:47 AAS
>できたとしてもカーネルドメインのみに絞ることは容易なので，誰でも変更できるというのには当たらないと思うよ．
そこですよ。
そう、容易といえばそのとおりで、保護ドメインもカーネルオブジェクトにして、それに
アクセス許可ベクタを設定できるようにすることで保護ドメイン別にアクセスできない保護ドメインの設定が
可能になる拡張も可能と考えている。 おっしゃるとおり「悪意あるアプリケーションの混入と攻撃については
あまり重視されていない」が、これである程度対応可能じゃないかと思っている。
ここで問題に思うことが2つある。
ひとつは、容易に拡張できることや、拡張することが当たり前になるとITRONのおおもとの目的である
アプリケーションの標準化が難しくなる。もう今は当初のITRONの本来の目的からはずれて
新たな目標に向かっているのかもしれませんが。
省9
613: 2010/11/02(火)22:12 AAS
払うだけ無駄でしょ
614: 2010/11/02(火)22:33 AAS
>石のバリエーション多すぎて考えても徒労ってことがあるからね．例えば，メモリ管理で実行可能フラグが
>落とせない石で，スタック壊されたらなんでもできちゃうよね．
もともとすべての石で対応できないものだし、MMUのおまけでMPU(メモリプロテクションユニット）の代行しているもの
も含めて考えるとそうかもしれないけど、今後は、命令フェッチのみ禁止するMPUは増えるように思うんだけどな。
615(1): ITRON名無しさん ◆4WD27e3i1o 2010/11/02(火)23:18 AAS
>>612
> 「明らか」というので公の情報なのか
HRPのソースコードは公開されているので，読めば理解できるはずだよね．
ただ，ぼくもきみもコンパイラではないし，ソースコードには経緯が書かれていないので，これを公の情報といって良いのかどうか．人間であるぼくには躊躇われるって話だと思ってほしいな．
ソフトウェアにおける"不具合"というのは幅広いけれどね…会員になったから細かいバグ情報が手に入るかというと，必ずしもそうでもないよ．特にターゲット依存部に関してはね．
狭い意味での不具合情報の収拾や修正依頼を期待するのであれば，活発そうな会員企業とサポート契約するか，自信があるなら自前で修正すると決断したほうがよいかもしれない．
この目的でのお布施は，ぼくも勧めない．
ただ，なぜこのような仕様になっているのかという情報収集や，この仕様はおかしいといった表明は，会員になったほうがはるかに効率的じゃないかなとは思うよ．
ETとかESECとか学会とかで中の人を捕まえてもよいと思うし，中の人も，お布施無いから対応しないってこともないと思う．けれど，効率はあまりよくないんじゃないかな．
好き好きだけれどね．ここはチラ裏だものね．
上下前次1-新書関写板覧索設栞歴
あと 265 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 2.234s*