(toppers-users 3693) Re: 保護拡張仕様(μITRON4.0/PX)の疑問点とその対応アイデア

[kazuhiro takahashi]

MLの皆様、村中様　おはようございます。アライブビジョンソフトウエアの高橋です。

On Sat, 5 Nov 2011 09:07:15 +0900
Masaki Muranaka <monamour ＠ monaka.org> wrote:

> > ひとつ言えることは、検証コストについては、ユーザーメーリングリストで議論する話題ではない
> > と言えばご理解いただけるでしょうか？
> 
> どうして検証だけに拘るのですか? 私は，時間性能の低下についても(というかむしろそちらを)
> 指摘しています．また，それが不可避とは言わず，可能かどうかを検討すべきと言っています．
> HRP2のコードは表には出ていませんが，HRPのソースコードは読めます．開発者以外の検討が
> 不可能なものとも思えません．
> 

村中さん、ちょっと混乱してませんか？
話を絞ろうと書いて、検証に絞った話をしたのは村中様ですよ。
toppers-users 3687をよく読みなおしてください。また、それについても指摘行にそれぞれの
論点にわけて私はコメントさせていただいています。
性能低下に関しては、その後に別サブジェクトでご相談しようと書いていますよ。

それと検証コストについては、先ほどのtoppers-users 3687でそれほどでもないと個人的見解が
書かれているので、これについては議題からおろすのはそれでOKですか？


それから発散してしまいそうですが、また別のスレッドで話できればと思いますが

> HRP2のコードは表には出ていませんが，HRPのソースコードは読めます．開発者以外の検討が
> 不可能なものとも思えません．
と前後しますが
> 仕様決定およびターゲット非依存部開発は高田先生，
保護機能カーネルのポイントになる部分は、ディスパッチャーだと思いますが、ざっと見たところ
見当たらないのですが、この部分は非公開なのでしょうか？



> また，私がHRPの開発者だというのは，微妙に事実誤認です．(←この点の誤解で，ずいぶんとすれ違っている気がします)
> 仕様決定およびターゲット非依存部開発は高田先生，配布パッケージにあるターゲット依存部は
> 開発もなみソフトの柳川(当時在籍)，コンフィギュレータの開発はきじねこの高木さんです．
> もちろん，立場上仕様決定の瞬間に立ち会ったり，揺れる仕様の中でパッチ書きまくったりましたが，その程度です．
> 検証工数の話でさえも，TOPPERSカンファレンスを始めとする関連講演の内容から大まかな当たりをつけており
> 非公開情報を押し付けてもいません．
> HRPの仕様決定/実装に関しては，私を"初期から知っているヘビーユーザーの一人"と見做したほうが実態に合っています．
> 

十分な開発者だと思います。誰も村中さん一人が開発者だとは申しておりません。十分にプロジェクトの状況が
把握できる立場であることは認識できます。もともと開発者であるか否かという表現が良くなかったのかもしれません。
正確には開発プロジェクトのメンバーという表現であれば誤解がなかったかと思います。開発プロジェクトのメンバーであれば
検証にかかる難易度やコストが十分把握できるものと思います。これらの情報はHRP以外のカーネルにおいてもどのような検証
作業が行われたかについては、少なくとも非会員は知ることはできません。会員にも公開されているものかどうもかも
わかりません。こういう部分での情報格差が、開発メンバーである村中さんと私の間にはあるということを指摘している
だけのことです。　まぁ上記のレスで書いたことなので検証に関しては議題からはずれるならコメントする必要も
なかったことかもしれませんが。

総括しますと、検証に関して議題からはずし、時間性能低下の話に進めてよいかどうかという
ことになりました。
ほかにもいろいろご指摘いただいても結構ですが、ひとつひとつ了解をとってから話を進めたいと思います。


ご検討よろしくお願いします。


> 
> 
> 2011年11月5日7:02 kazuhiro takahashi <takahashi_kazuhiro ＠ nifty.com>:
> > MLの皆様　村中様　おはようございます。
> >
> > On Fri, 4 Nov 2011 22:35:26 +0900
> > Masaki Muranaka <monamour ＠ monaka.org> wrote:
> >
> >> 高橋さん，みなさま:
> >> こんばんは．
> >>
> >> 発散させてしまったようなので，少し絞ります．
> >> 大事なところを無駄に絞っているようならご指摘ください．
> >>
> >> > こういう前提で考えた場合にどうでしょうか？　という話をしているわけです。
> >> > そういう前提が成り立たなければ話にならないのは、最初から認めています。
> >> > さらにこうすればこのようにできるね。　といわれて、強迫観念的に作らなければならないという考えなのでしょうか。
> >> > すぐに検証に時間がかかるとかいう話になってきたりします。
> >>
> >> ええと，全て仮定の話という前提に立つとしても，その仮定の副作用として，
> >> 「それどう検証するの」「時間性能どうなるの」という意見が出るという仮定は容易にできますよね．
> >> 「検証のことなんて考えなくても良い」という仮定ももちろん(言葉の上では)できますけれど，
> >> しかしそんなカーネルを PX/HRP/HRP2 のユーザが使いたがると仮定できるものでしょうか．
> >> または「検証の工数なんて現実的な範囲に収まるよ」という仮定が成り立つとかでもよいのですが…．
> >> 莫大な潜在ユーザが発現するので検証コストなど相対的にケシ粒になるという仮定も
> >> ありかもしれません．単に技術の問題ではない評価が必要になるかもしれませんけれども．
> >>
> > 同じことのどうどうめぐりですね。
> > ひとつ言えることは、検証コストについては、ユーザーメーリングリストで議論する話題ではない
> > と言えばご理解いただけるでしょうか？
> > 少なくとも、村中さんは、HRPの開発者かと理解しています。検証作業そのものも自ら行ったか
> > 行っていないにしても、どのように実施されたかよくご存知かと思います。自分はTOPPERSに関しては
> > 一般のユーザーの一人です。　検証作業がどれだけのコストがどれだけかかるかを両者で議論する
> > こと自身不毛かと考えます。
> > ただ、自分もRTOSの検証作業やパフォーマンス計測など長年実施しています。
> > ここでTOPPERSでは検証ができない/できるという2者択一の論議をするのはいささか、気がひけます。
> > 繰り返しになりますが、このユーザーMLで議論するのは少し違うと思います。
> > ただ、現在において、TOPPERSの実作業者ではないということですので、それを村中様の見解で
> > 難しいと語るのは結構ですが、それは本来、現在の当事者が言うことだと思います。
> >
> >
> >> 個人的には，検証工数の増分はさほどではない気はしています(って書くと検証チームに刺殺されるかも)けれど，
> >> 先のメールで長めに書いたとおり，ほぼ全てのサービスコールに係ってくる時間的なオーバヘッドは
> >> どうなのかなというのは気になります．
> >> // ただでさえ割り込み禁止区間が長いと陰口叩かれているTOPPERSですから．;-)
> >>
> >
> > 陰口は自分かもしれませんが、今度は別サブジェクトでそれについて提案したいと思っています。
> > お付き合い願えますか。
> >
> >
> >>
> >> 実装への強迫観念はありません．ただ，一般論として実装のニーズが無い仕様は不自然ですし，ましてや
> >> μITRON仕様とは違ってTOPPERSの仕様書は実装仕様を謳っています．
> >> 仕様の拡張を仮定するなら，リリースまでに起こる系の全て，とは言わないまでも有り得そうな物事は
> >> 仮定しないと片手落ちだろうとは思います．
> >>
> >
> > なんとも言いがたいですが、一般論とか、ニーズが無いとか、ものさしがどこにあるのか
> > なんとも言いがたいですね。
> >
> >>
> >> > 動的生成＆保護機能カーネルは世の中にあるかないか調べたのでしょうか？
> >>
> >> 調べるも何も，静的生成のほうが圧倒的に少ないと思いますが…．
> >> POSIX準拠の少なからずのカーネルはその枠に入りますね．
> >> Javaなどの言語レベルで保護が入るもの書かれたカーネル群も概ね入りますし．
> >> ご近所だと T-Kernel もですよね．
> >
> > 多いか少ないかという話ではなく、あるか無いかということから話が変わっていますよ。
> > 思いますがということは調べていないということですね。
> >
> > 全体的な反論の仕方として、両者が互いに正しい方向に向かう議論にしたいと思っていますが
> > 反対論の繰り返しや、反対論の違う視点のまぜての意見などディベート主体のご意見かと
> > 思います。誰もが自分は正しいと思って意見は述べるかのはわかりますが、その点
> > ご理解の上整理して、ご意見いただけると幸いです。
> >
> >
> >
> >>
> >>
> >> 2011年11月4日21:03 kazuhiro takahashi <takahashi_kazuhiro ＠ nifty.com>:
> >> > こんばんは、
> >> >
> >> >
> >> > On Fri, 4 Nov 2011 19:56:54 +0900
> >> > Masaki Muranaka <monamour ＠ monaka.org> wrote:
> >> >
> >> >> 高橋さん，みなさま:
> >> >> こんばんは．
> >> >>
> >> >> > 動的生成の必要性自身がなければいらない技術かもしれません。それはそうかもしれない
> >> >> > と思います。
> >> >>
> >> >> 要らない(もしくはユーザがいない)技術を仕様に盛り込むリスクを，仕様を考える際は常に感じなければ
> >> >> いけないですよね．
> >> >>
> >> >> 一般論として，検証工数がべらぼうにかかるシステムでは，キホンはユーザドリブンにならざるを得ません．
> >> >> 美しいから可能だからという理由で仕様を弄るのは，なかなか難しいのではと思います．
> >> >> // いまやTOPPERSの中の人ではありませんので，個別事案でどういう判断になるかは知りませんが．
> >> >>
> >> >>
> >> >
> >> > こういう前提で考えた場合にどうでしょうか？　という話をしているわけです。
> >> > そういう前提が成り立たなければ話にならないのは、最初から認めています。
> >> > さらにこうすればこのようにできるね。　といわれて、強迫観念的に作らなければならないという考えなのでしょうか。
> >> > すぐに検証に時間がかかるとかいう話になってきたりします。
> >> > つい先日、村中さんの話の中でコメントしたことですが、できないという結論を導くのはできるという結論をだすより難しい
> >> > ということです。時間やコストを踏まえてもそうだと思います。無料のようなコストでとか今すぐにという状況ではできないのは
> >> > 間違いありませんが。
> >> >
> >> > まず可能性を考える。次に実現性を考えます。今まで可能性がどうかという話をしているかと思います。
> >> > ところがいきなり実現性の話を持ち出す場合があります。これもひとつのディベートかもしれませんが
> >> > お互いに建設的結論を導き出す方法とは違う方法のように思います。
> >> >
> >> >
> >> > ユーザーニーズはどこにあるのかというのは、私にしても、少なくともTOPPERSプロジェクトとしてもあまり得意な分野では
> >> > ないように思います。ちょっといいすぎかもしれませんが、TOPPERSにしてもユーザーニーズに沿ったものにする取り組みもされてきて
> >> > いると思いますが、ユーザーニーズについて語れるほど情報はここにはないと思います。
> >> > このユーザーニーズの話、つまり動的生成＆保護ドメインカーネルオブジェクトについてのニーズの有無は、水掛論のように
> >> > 思います。
> >> > ただ、ちょっと自分が卑怯ないいわけを最後にするとすれば、動的生成＆保護機能カーネルは世の中にあるかないか調べたのでしょうか？
> >> >
> >> >
> >> >> > ただオーバーヘッドに関しては、動的生成そのもののオーバヘッドから考えると、単純に
> >> >>
> >> >> 保護ドメインのID化は，ゼロオーバヘッドになりえますか?
> >> >>
> >> >> たとえば [a]cre_dom なるサービスコールがあったとして，その処理時間は相応に時間ががかかるかも
> >> >> しれません．そして，何度も呼ばれるサービスコールではないので，システムの寿命におけるこれら
> >> >> サービスコールの実行時間の割合はたかが知れているのは確かに言えそうです．
> >> >> しかし，各サービスコールでは，評価時にそのIDが有効であること(生成されていて削除されていないこと)
> >> >> を確かめる必要がありますね．おそらく割り込み禁止区間内にです．
> >> >> これも大したことがないかどうか，それはもちろんアプリ次第です．
> >> >>
> >> >> 最優先で護るべきリソースが"時間"であるはずの RTOS で，そのオーバヘッドを許すに足るだけのメリットを
> >> >> 享受できるアプリが具体的に存在するならば，動的も考えるべきかもしれませんね．
> >> >>
> >> >
> >> > この部分もアプリがなければ必要ないという話と検証にかかるコストのことですね。
> >> > ということは、アプリに必要性が認められ、さらに検証可能（適切なコストでの）であればいくらかの
> >> > 有効性は認めるということなんでしょうね。
> >> >
> >> >>享受できるアプリが具体的に存在するか
> >> > これも先日、村中さんに回答いただいたものです。SafeGなら該当するでしょう。ただ、TrustZoneというハードウエア依存かと
> >> > 思います。保護機能もハードウエア依存なので、ハンデは同じかもしれません。
> >> >
> >> >
> >> >
> >> >>
> >> >> > これは少々乱暴なご意見かと思います。
> >> >>
> >> >> plan9のセキュリティモデルが乱暴なのか，組込みシステムへの適用が乱暴なのか，どちら方面からのご指摘でしょうか?
> >> >
> >> >
> >> >>「どんなに優れた認証システムを作っても，認証サーバのコンソールに悪人を置いたら終わり」と見切ったPlan9
> >> > 見切ったということはPlan9以外の認証サーバーに悪人おいたらおわりのものはまったくだめという話です。
> >> > これが乱暴以外のなにものでもないと思いませんか。
> >> >
> >> >
> >> >
> >> >>
> >> >> 私も実は心配性なので，ときどき鍵は多ければ多いほどよいと思ったりはします．
> >> >> ですが分厚いリングプロテクションの Mutlcis が失敗の母で root/user だけの Unix が生まれたという人もいます．
> >> >> もちろん，揺り戻しもありますね．
> >> >> 明らかにノーガードなのは論外ですが，保護がどうあるべきかというのは，時代とか使えるリソースとかで決まるので，
> >> >> どれが乱暴とか乱暴でないとか一概に言えるものではないかなとも思います．
> >> >>
> >> >
> >> > 少し誤解されているようで残念ですね。
> >> > 書いた内容が不適切で誤解を招くことはあると思いますが、疑問点に関して確認したうえで相手を尊重してご意見したいと
> >> > 思っていますし、議論する相手についてもそれを期待したいですね。
> >> >
> >> > --
> >> > kazuhiro takahashi <takahashi_kazuhiro ＠ nifty.com>
> >> >
> >> >
> >>
> >
> >
> > --
> > kazuhiro takahashi <takahashi_kazuhiro ＠ nifty.com>
> >
> >
> 


-- 
kazuhiro takahashi <takahashi_kazuhiro ＠ nifty.com>