KOZOS(Kernel Over Zone Operating System)は教育用というか， 勉強用，独学用，いじって遊ぶ用のOSです．
OSというと動かすのにインストールしなければならないというか， いじるにしても環境作りがまずちょっと面倒であったり， まずはターゲット機を購入する(もしくは探すところから)必要があったり， いろいろ試すにしてもフラッシュへの焼き込が必要とかで気軽に試せなかったり， デバッグが大変であったりというようなイメージがあります． まあ最近のOSはそうでもなかったりするのだけど， PC上で１アプリとして気軽に(ここ重要！)ビルドできて， 組み込みOSっぽく動くようなものがあったらおもしろいかなーくらいの感覚で， 自分の勉強として作ってみました． というわけで分類的にはOSというよりもスレッドライブラリのような 気もするのだけれど， スレッド管理や資源管理(CPU時間も資源のひとつです)など， やってることはOSとだいたい同じなのでここではOSと呼んでいます． そもそもスレッドライブラリを作ることが目的なのではなく， 勉強用のOSとして，構造は組み込みOSなのだけどPC上で動作する， という路線で作っています． 設計も，スレッドライブラリではなく組み込みOSに似せること (組み込みOSならば，こーいうふうに動作するべきなんだろうなーという視点) を主眼に置いています． つまりスレッドライブラリとしての実用性とかではなく， KOZOSの動作がわかれば組み込みOSの動作もわかるようになる(んではなかろうか) という，そーいうつくりを目指しています． そーいう意味では，疑似組み込みOSというのが正しい言いかたかもしれません．
実は Toppers ではそのようなことができて，Linux とかのOS上で動く スレッドライブラリとしても使えたりするのだけど， まあKOZOSは PC-UNIX 上での動作のみに限定して， とっつきやすさ，わかりやすさ，読みやすさ，いじりやすさを テーマにしてみようかな，と． そういう意味で，組み込みOSやスレッドライブラリは既にいろんなものがあるけど， こんなような勉強用の疑似OSって今まで無かったような気もする． (あったら筆者の無知です．ゴメン)
とくに，気軽にビルドして試せるということは非常に重要． 社会人になると学生とは違い，まとまった時間で どっしりと構えてじっくり勉強できることってそうそう無くて， 皆無ではないし，そういう時間を自分で作ろうとすることも大切だけど， やっぱしあいた時間とかでちょこちょこマメに勉強する，とか， 通勤電車の中や家に帰ってからヒマを見つけて， あした(明日，ではなく，未来という意味ね)のためにちょっと勉強しておく， という技術が必要になってくる．なので， まずはターゲットマシンの確保とビルド環境の整備に３日， 実機で動作するようになるまで苦戦してさらに３日， ソースコードの読破に１週間なーんてのはそれが本業ならばいいのだけれど， 自分の勉強としてはなかなか難しい(モチベーションを保つのも難しい)ので， こーいう単純なサンプルコードで暇な時間(通勤電車の中とかね)にパッと勉強できる， コード量が少ないので紙に印刷して持ち歩いて暇な空き時間に読める， 規模が小さいので簡単に手が入れられて，いろいろ試しながら楽しく勉強できる というのは，とっかかりとしてとても大切だと思う．とっかかりさえできれば， あとはそれなりに巨大なソースコードを見てもなんとなく何やってるかくらいは わかるようになるものです．
組み込みOSの勉強をしていると， 「再入」「プリエンプティブ」「リアルタイム性」「排他」「同期」 なーーんて言葉というか概念がいっぱい出てくる． そして，それらを説明している資料もいっぱいあるのだけど， やはり理論的な説明だけではわかりにくい． しかしこれらのことを実際に試してみるとすれば， きちんとした組み込みOSを用意して，ターゲットボードにインストールして， お試しアプリを作成して動かしてみる，ということになる． もちろんコンパイル環境作りから必要だし， どんなふうに動いているのかを確認することすら，場合によってはたいへんだ (printf()が使えなかったりね！)． しかしこれでは初心者はとってもとっつきにくい． なので，気が向いたときにPC上でパッと試せる，実際に何が起きているのか， 動作させてみて見てみることができるというのは， とてもとっつきやすくていいと思う．PC上での動作ならば， printf()とかでログを出させるのも自由自在で融通が効く． そーいうためのサンプルOSとしたい，という考えもある．
あとはGDBによるリモートデバッグに対応させたいというのもある． リモートデバッグに関する雑誌記事とか国産の資料とかってとっても少ない (ていうかほとんど無い)のだけれど， 無いからにはちゃんと書かないとなーという思いもある． 組み込みやるならば必須の機能だと思うし， ということで実はKOZOSはリモートデバッグのGDBスタブ実装のためのサンプルOSとして 作ったというのもあるので，とくにリモートデバッグのスレッド対応に関して， きちんと実装させてみたい． KOZOSでリモートデバッグが実装できれば，実際の組み込みOSでも原理的には 同じように実装できるはず．なので，このようなサンプルコードはどこかで必要と されているはずだ！
ちなみにOSの作成，i386のリモートデバッグ化，リモートデバッグのスレッド対応 とも，ぼくはKOZOSが初体験となります．どんなものになることやら！
組み込みOSでもスレッド化でもそうなのだけど，実際にアプリ作成をやってみると， 非常に新しいパラダイムというか， あーこんなプログラミング手法もあるんだなーと思う． たとえば telnet によるコマンド受付と http サーバと定期的な時計表示と デモ画面のリアルタイム動画をひとつのアプリでぜんぶいっぺんにやろうと したらどうするか？ いちばん単純なのは，signal()でSIGALRMのハンドラ登録してalarm()でタイマかけて select()で待つ，という実装でしょう． でもたとえば telnet でのコマンド実行処理で数秒に渡ってCPUを占有してしまう ような重い計算処理とか，httpサーバで処理途中に応答待ち合わせとかしたい 場合とかあったらどうするのか？alarm()でタイマかけて定期的に呼んでもらうか？ うまくやらないと時計は固まるしリアルタイム動画はカクカクになるし， あーめんどくせー．
でもこーいうのはもう時代遅れ！ スレッド化の手法を勉強すると，プログラミングとデバッグに新しい道が 見えてきます．その道が常に正しい，というわけではないけれど， ひとつの手法として，勉強する価値はおおいにありますよ！