ちょっといまさらなのだけど， 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を何も知らない人でも，一生懸命読めば理解できるし簡単に試せる，というものに したい．