(注意)このブログは本家のほうの文章部分のみの転載です.ソースコードの配布,画像などについては本家のほうを参照してください.文章中のリンク先は面倒なのですべて本家のほうに変換してしまっているのでご注意ください.

最近はInterfaceの記事が忙しくてKOZOSがあまりいじれていないのだけど,前からちょっと思っていたことについて.

KOZOSの方向性についてで,方向性について書いたけど,もうひとつ,こんな方向性で作ってみたいなあという前々から思っていたネタがある.

それは,デバッグ機能というものだ.

組み込み系に限らず,アプリケーションプログラムでも,いかにデバッグするかというのは永遠の課題だ.とくにメモリ系のバグ(バッファオーバーランや2重解放など)は非常に原因を特定しにくく,方法もあまり確立されていなかったりすることも多い.

個人的な考えとして,このようなデバッグ機能はOS側で持っていてもいいと思うのだな.たとえばKOZOSではkz_kmalloc()というシステムコールでメモリ獲得できる.このときに,kz_kmalloc()を呼んだ箇所(関数からのリターンアドレス.PowerPCならばLRレジスタの値)をメモリヘッダ上にメモしておくなどして,あとでメモリ領域を見たときに,その領域がどこで獲得されたのかひと目でわかるようにしておく,などだ.

他にも kz_send() によるメッセージ送信時に,やはりそれを呼んだ箇所をメッセージヘッダ上に保存しておくとか,呼ばれたときの時刻を保存しておくとか,呼んだスレッドのスレッドIDを保存しておくとかだ.あとは,システムコール呼び出しのトレースを保存しておくとか,スレッド切替えのトレースを保存しておくとか.

このようなデバッグ機能は,ライブラリで実装すべきという意見もある.まあアプリケーションプログラムだと,デバッグ性を強化したメモリライブラリなどは昔からあって,2重解放などを検知してくれたりはする.

しかし今の時代,OS側でこれくらいのデバッグ機能を持っていてもいいと思うし,OSでないとサポートできないようなデバッグ機能もある(スレッド切替えのトレースなどはその典型).そもそもデバッグ用のログなんて常にとっておいてほしいものなのだから,ライブラリを使ったときだけなんていうケチなことは言わず,OS側で常にとっておいてくれてもいいと思う.

とくに組み込みOSというと,「可能な限り小さくコンパクトに」「無駄は極力省いて」「最低限必要なもののみ実装」といったような考えが根強く,デバッグ用のログを(そのためにメモリを余分に使って)残すなんてとんでもないと,のっけから否定されてしまうことも多いと思う.しかし今の時代,メモリ使用量をキロバイト単位で節約することよりも,デバッグにかかる工数を削減することのほうがよっぽど重要であることも多いだろう.まあそうではなく相変わらずバイト単位でメモリを削ることが必要なこともあるだろうが,今となってはそちらのほうが少数派なのではなかろうか.もしくは「少しでも削らないと」という古い考えにとりつかれているだけで,もはや誰もそんなこと望んでない,ということもあったり無かったり...?

けっこう意味不明なのは,「デバッグ用のログなんてメモリを余分に使うのだから,実装すべきではない」とか言っておいて,「どうしても必要ならばライブラリで実装すべき」とか言われたりすることだ.ライブラリで実装したほうが,メモリを余分に使うことになるのだけど...?無駄を省いてOSはコンパクトにしたい,というのはわからなくもないが,そのせいでライブラリが肥大化して全体としてサイズが増えたら本末転倒では?と思うのだが.

デバッグ機能もそうなのだが,実はOSでサポートすべきで,OS側が対応すればきれいに解決するのだけど,OSに手を入れられないのでライブラリでなんとか実装する,という機能は実際に多いと思う.OSに売りものを使っていたりするとなおさらだ.

自前で独自OSを作って利用していることも多いと思うが,アプリだったらガンガン改良するのだが,ことOSとなると,なぜか手を入れるのを極端に敬遠されるということもあるように思う.「OSは極力いじらない」という考えが,根強くあるように思う.

OSでサポートすべきなのにOSに手を入れられず(もしくは手を入れることを恐がって),ライブラリやアプリ側でがんばって対処する,というのはとてももったいないことだ.だってOS修正すれば済むことじゃん!というわけだ.OSだって普通のプログラムなのだから,手を入れるのをためらう理由はあまりない.(失敗するとシステム全体がおかしくなるので恐い,というのはわかるが,そのためにきちんと修正案を吟味して十二分にテストをすればよい.恐がってOSには一切手を出さず,ライブラリで頑張って対処してよけいに工数が増えるというのは本末転倒)

なので,そのような機能をKOZOSを使って実験・実装してみて,「OSは極力いじらない」という世の中の風潮を「OSは改造してあたりまえ」という考えに変えていければなあ...そのようなOS改造時の際のサンプルにすることができればなあ...という思いがちょっとある.とくにデバッグ機能に関しては,いろいろお試しで実装してみたい.これは,仕様がガッチリと決ってしまっているμiTRONではできないことだ.

デバッグはもはやOS側でサポートする時代だ!と個人的には思うのだ.
AD

toppers移植

テーマ:

toppersの移植作業だけど、とりあえずかなり雑だけどひととおり必用な部分は書いて、コンパイルが通った。

あとはボードにダウンロードして試すだけ。

うまく動くといいなあ。


AD

Toppers移植

テーマ:

ちょっと別件(もちろん本業ではない)でToppersの移植作業を進めているのだけど、ようやく必要部分は書いてファームウエアがビルドできるようになった。


で、ボードで試したいのだけどボードが起動しなくなってしまった。。。なんてこったい。


Toppersのソースコードって、かなりきちんと整理されてていいね。おかげで移植もすげーしやすいし、いろいろためになる部分もいっぱいある。うーん、参考になるなあ。



AD

Toppers

テーマ:

ようやくInterfaceの連載原稿をあげてひと段落したので、OSC関西に向けてKOZOSの開発を進めたい。


進めたいのだが。。。ちょっと別件でToppersをいじっている。なんとか移植できないかな。


う~ん、KOZOSもっと開発進めたいのだが。やりたいことはいっぱいあるのだけど仕事(本業のほうね)も忙しくて時間が無い。。。


Toppersおもしろいね。こちらは本業ではないのだけれど。