オープンソースカンファレンス2009 Kansaiに出展した

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

7/10(金)～11(土)に京都駅近くの京都コンピュータ学院 京都駅前校で開催された，オープンソースカンファレンス2009 Kaisaiに出展してきました．前回とは異なり，単独ブースでの出展です．

いやいや，楽しかったですね．いろいろな人に話を聞いていただけました．わたしの説明に時間を割いていただいた方々，どうもありがとうございました．応援していただいたり，いろいろアドバイスなどもいただけで感謝です．他のコミュニティの方々ともいろいろ話せました．

で，KOZOSなのだけど，現在ちょっと本業が忙しいのと，週末はこっちの連載を書くので手一杯状態なのでちょっと開発が進んでいません．．．OSC関西でKOZOSの説明を聞いていただいていまこのページを見ているかた，ごめんなさい．

とりあえずOSC関西で紹介したPowerPCボードへの移植ですが，Interface誌の記事についてきちんと情報公開していなかったので，雑誌記事についてはこっちに書いておきました．ソースコードも公開してあります．あとはPowerPCへの移植については，「独自OSを作ってみよう！」の下のほうの「移植編」を見てみてください．まあ思っていることは，こことかここにいろいろ書いてあります．

で，ちょっとOSCで思ったこととして．．．

やっぱしデモが地味だね．なにかマイコンボードとかに移植して，実機で動作しているところを展示できたらいいなあ．次回のOSCは名古屋に出展する予定だけど，秋月のH8ボードか，Interface誌の付属ARM基板あたりに移植できたらいいなあ．

あと，説明を聞いてくれたかたのひとりに学生さんがいて，「組み込みOS自作って興味ありますか？」という言葉に目をキラキラと輝かせて「はい！」と返事をしてくれたかたがいた．いやー，いいねえ．こういう人達と話をすると，やっぱしもうちょい頑張って作ろうかなって思います．(昔の自分を見ているようだ)

他にも新社会人のかたとか，専門学校のかたとかで，興味を持ってもらえて積極的に質問してくれたかたもいた．で，そーいうかたたちと話をして思うことなのだけど，やっぱし組み込みOSって，興味のある人はけっこういる．これは，OSCの短い日程の中だけでもそういう何人かと出会うわけなので，実際にけっこういるのだと思う．

そして多くの場合，興味はあるのだけど，実際どうやって勉強したらいいか，作るとしたらいったい何をすればいいのかわからない，ということがハードルになってしまって手が出ない，という人が多いようだ．KOZOSの開発をもっと進めることで，なんとかそのへんの解決になればなあ，と思う．なにせKOZOSのような単純なサンプルOSは，自分自身が組み込みOSを独学で勉強し始めたときに，ものすごーくほしかったものだからだ．

Interface2009/07号でKOZOSが紹介されています

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

ちょっといまさらなのだけど，CQ出版の「Interface」の2009/02号から「実践的PowerPC活用テクニック」という連載を書いていて，第12回の2009/07号で，KOZOSが紹介されています．５月末の発売なので，ホントいまさらですな．(読みたい人はバックナンバーを買って！買うときには「KOZOSの記事が読みたくて」と出版社に言ってね！)

内容は，BLANCAのPowerPCオプションボードにKOZOSを移植する，というものです．ついでに次の号では，KOZOSをベースにGDBスタブ移植してGDB対応しています．

KOZOSのソースコードは雑誌掲載用に必要最低限の内容にしぼってあります．で，連載のサンプルプログラムをダウンロードできるようにするのをすっかりさぼっていたのだけど，ここからダウンロードできるようにしときました．興味ある人は見てみてください．KOZOSの移植のソースコードは，「第12回(2009/07号)のサンプルプログラム」というやつです．あと第13回のほうでもGDBスタブ実装のためにKOZOSを利用しているので，そっちも参考になるかも．

ちなみに上記ソースコードなのだけど，連載の以前の回のファイルもそのまま残ってしまっているので，ちょっといろいろあります．が，pci.[ch]やled.[ch]などはKOZOSの動作にはとくに無くてもいいもので，KOZOSのコア部分だけに関してならばだいたい700行くらいです．

% ls
KL-01           crti.c          led.c           memory.c        startup.s
LICENSE         crtn.c          led.h           memory.h        syscall.c
Makefile        extintr.c       lib.c           pci.c           syscall.h
command.c       idle.c          lib.h           pci.h           thread.c
configure.h     kozos.h         main.c          serial.c        thread.h
crt1.c          ld.scr          make.sh         serial.h
% cat kozos.h memory.[ch] startup.s syscall.[ch] thread.[ch] | wc -l
     698
% 

で，ここで言いたいのは「KOZOSは小さくてすごいでしょ！」ということではなくて(小さいとは思うが，すごいとは思わないので...)，「OSってたったのこれだけでも書けてしまうんです」ということです．まあこのへんのことはこっちでいろいろ書いているのでそっちも読んでほしいのだけど，こんだけでいいなら，OSってもしかしたら自分でも作れちゃうんじゃないの？とかいう気になるでしょ？

どの程度の機能があればOSと呼べるのか？ VGA無いのでは話にならん！ネットワーク機能も無いのでは実用にならん！ファイルシステムは必須だろう！といった意見は多々ある．しかし，それらって別にOSの機能ではないと思う(UNIXはファイルシステムOSなので，動作のためにファイルシステムが必須だが，それはUNIXがそうなだけであって，OS一般の話ではない)．これはぼくの勝手な持論なのだけど，スレッド管理とメモリ管理とデバイス管理だけあればOSと呼べると思う．というのはコンピュータ・システムの３大要素がCPUとメモリとI/Oであるので，その３つを管理できれば，コンピュータ・システムを管理しているといっていいと思うからだ．

会社の若手とかがちょっと志を持って，個人的にOS勉強してみたいなーと思ったり，大学生やもしくは高校のパソコン部とかで，自分らで独自OS作ることはできないかと挑戦してみたくなったときに，サンプルとしてLinuxとかμiTRONとかを見てしまうと，巨大すぎてたいていはまあ己の無力さを感じるだけの結果となってしまうと思う．(それでも「作ってやるぜ！」と思うような人はこのページを見なくても勝手に作ると思うので，それはそれでいいですが)

しかしたとえば今回のKOZOSの移植例のように，たったの700行ていどなら「自分でも作れるのではないか？」「少なくとも，頑張ってソースコード読めば全貌を理解できるだろう」と思えるじゃあないですか．

そーいう意味でKOZOSはあまり機能追加してコード量を多くはしたくないし，将来的にデバッグ機能とかを追加していくとしても，それは別コードとして独立させて，簡略化してあるソースコードはちゃんと残したいと思う．多CPU対応するときもそうで，本来ならハードウエアを仮想化して移植性を高くしてソースコード共通化する，という話になるのだけれど，KOZOSの場合はCPUごとにソースコードを独立させて，シンプルさを確保したいと思っている．

というのは「ハードウエアを仮想化してソースコード共通化する」というのはプログラムの書き方の勉強であって，OSの本質の勉強とはあまり関係の無いことであり，そっちはそっちで別に勉強すべきことだと思うからだ．

これに関しては反論多そうなので一応書いておくけど，「勉強しなくていい」という意味ではないよ．ただOSの勉強したいときに，OSの本来の動作(スレッド切替えとか，割り込み処理とか)の部分のソースコードが難しくてわかりにくいというのはしょうがない．それはOSを知るためにはそれを理解することが必要，ということだからだ．しかしソースコード共通化などの別原因で(#defineの定義や関数呼び出しが深くなってしまい)ソースコードが追いにくくなっていて，本来やりたい「OSの内部構造の勉強」の妨げになるのはよくないと思う，という僕の考えだ．矛先が違うということだ．

で，そのようなあまり関係の無いことのために読みにくくなってしまい，「OSの内部構造を知りたい」という本来の目的から離れてしまうのは避けたい．もしもそのような書き方が必要なら，必要となった人が必要なときにそう書けばよいだけのことだ．

もちろん，700行程度でできることは少なくて，雑誌掲載用にシステムコールも必要最低限だけにしぼってある．だけどこれは「機能が貧弱なので実用的でない」ということではなく，「機能は最低限しか無いので，ほしいサービスがあればシステムコールを自分で追加してみたらどうだろう」「そもそも機能が貧弱すぎてKOZOSはダメだと思うならば，自分でスクラッチで書いてみてはどうでしょう」という僕のメッセージだと受け取ってほしい．

KOZOSでのシステムコールの追加は簡単だ．syscall.[ch]にシステムコールの入口があるのでそこにてきとうに追加して，実際の処理を thread.c に書くだけだ．セマフォとかほしければ，簡単に実装できると思う．改造しやすい，機能追加しやすいということは，KOZOSの最大の魅力のひとつだと思う(中身をたいして読まなくても，誰でも改造できます)．いろいろお試しで機能を入れてみて実験するためのベースOSにするというのはとてもいい使いかただと思う．なにせ僕自身が，たとえばGDBスタブ実装の実験とか，GDBスタブのスレッド対応の実験とかのベースOSとして使っているので．

組み込みOSの勉強をしたいとき，いちばん手っ取り早いのは，何かてきとうなOSを拾ってきて動かしてみることだ．で，いろいろ実験してみるのがいいのだけど，その実験用にまあその拾ってきたOSを使ってもいいが，実験用のベースOSとして自作OSをひとつ持っておくと，いろいろと試すときにとても便利だ．

「KOZOSなんて貧弱だしダメだよ」と思ってもらっても構わないが，そのような人は自分で作ればいいだけのことだ．僕はべつに，KOZOSを実用OSとしてそのまま使ってほしいというわけではない．ただ「OS自作は難しい」というイメージを払拭し，OS自作のハードル(技術的なハードルというより，「難しそう」という意識的なハードル)を下げたいだけだ．

自分自身，個人的興味だけで組み込みOSを勉強したいと思ったが教えてくれる人はいなくて，独学でいろいろやってきたが，読解しやすくて試しやすいサンプルが無いことが一番のハードルではあった．

自分のそーいう経験が，ほかの似たような人のために役立てられればいいなあ，と思う．だからKOZOSは，OSの専門知識を持っている人や大学できちんと教わることができた人やμiTRONの勉強をきちんとした人だけが理解できるというものではなく，OSを何も知らない人でも，一生懸命読めば理解できるし簡単に試せる，というものにしたい．

KOZOSの方向性についてその２

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

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

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

それは，デバッグ機能というものだ．

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

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

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

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

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

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

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

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

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

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

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

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

toppers移植

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

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

うまく動くといいなあ。

Toppers移植

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

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

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