【TOPPERS】ITRON総合スレ3【NORTi】【HOS】 (880ﾚｽ)
上下前次1-新
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とか学会とかで中の人を捕まえてもよいと思うし，中の人も，お布施無いから対応しないってこともないと思う．けれど，効率はあまりよくないんじゃないかな．
好き好きだけれどね．ここはチラ裏だものね．
616(2): 2010/11/03(水)00:02 AAS
>615
コンパイラではないし とか、正直に公の情報がないと書けばすむものをまた文学的表現ですね。
>狭い意味での不具合情報の収拾や修正依頼を期待するのであれば
わかってて書いているかもしれないと思うけどTOPPERSにバグがあっても困らない立場ですが、仕様書が間違っていると少し
困る人です。ある意味TOPPERSの成果を業務に活用しているもっとも顕著な仕事かもしれないと思っています。
あくまでTOPPPERSのソースコードは仕様を把握するための手助けしかないわけですが
>ただ，なぜこのような仕様になっているのかという情報収集や，この仕様はおかしいといった表明は，会員になったほうがはるかに効率的じゃないかなとは思うよ．
ITRONばかり踏み込んで情報収集するならそうかもしれない。ある程度こぼれてくる情報収集だけで十分な話ですよ。
PXにしても、どれだけ市場ニーズのあるものなのと考えるわけです。ここのスレタイのNORTIなんかHPみてもいつの夏休みを記載しているの
というサビレようですよね。かなり前にどこかとタイアップしてPX仕様のを作るとか言ってたような気がしますがどうなったんだろうと思っています。
省2
617: ITRON名無しさん ◆4WD27e3i1o 2010/11/03(水)00:52 AAS
>>616
ええと，何を問題視しているのか判らなくなっちゃってるのだけれど?
リソースを管理するためにカーネルがあるのであって，管理できないカーネルなんてただのオーバヘッドだっていう考え方は，別段特殊でもない…よね?
Linuxがiopermで叩かれたり，BSDの/dev/memは?って不毛に罵り合ったりとかは，2010年のエンジニアでも履修しておくべき雑学...だよね?
その辺の破綻の末に，ハイパバイザってのが台頭したって気もするのだけれど，...これは見方により異なるだろうから同意を得るつもりは無いよ．
> ITRONばかり踏み込んで情報収集するならそうかもしれない。
ええと，TOPPERSを顕著に業務に活用しているけれど，ITRONばかり踏み込んでいられない…? よく判らないな．OSEK系ならITRON関係ないしね．"文学的"であることを真似してくれなくてもいいよ．
省2
618: 2010/11/03(水)02:09 AAS
>リソースを管理するためにカーネルがあるのであって，管理できないカーネルなんてただのオーバヘッドだっていう考え方は，別段特殊でもない…よね?
>616 では、カーネル管理外の話題は書いていないつもりなんだけど
>ええと，TOPPERSを顕著に業務に活用しているけれど，ITRONばかり踏み込んでいられない…? よく判らないな．
>OSEK系ならITRON関係ないしね．"文学的"であることを真似してくれなくてもいいよ．
真似してしまったね。解説するよ。単純に「今更」ということ、今はそうだけど、今後は必要なくなる可能性が
大きいという話。個人的な案件の話ということもあるが市場のニーズと遠いところにあれば、今までどおりでは
ないよね。NORTIの話もそういう流れのつもりで書いている部分もあるわけですよ。
単純に言うとITRONのシェアが高ければ高いほど、私の仕事が今後も続いていくだろうが、縮小するなら
別の道を考えないといけないと思うわけですよ。
TOPPERSのMLでM32CやR32Cの依存部や割り込み応答時間等まで回答している私がなにをしているかは
省8
619: ITRON名無しさん ◆4WD27e3i1o 2010/11/03(水)02:41 AAS
> 私がなにをしているかは
素で全然わからない．ていうか特定のターゲット依存部にしか興味のない人に敬意は払うけれど興味ない．ごめん．
620: 2010/11/03(水)05:04 AAS
一般人引きつけるための...
621: 2010/11/04(木)08:10 AAS
ITRON名無しさんが読んでないかどうかは知らないけど、
相手がTOPPERS-usersを読んでると決めてかかってない？
上下前次1-新書関写板覧索設栞歴
あと 259 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.015s