JSPカーネルにサブセットは必要か
TOPPERS界隈の最近の流行りは，壊れた日本語や長文で思いの丈で語ることらしいです．私が叩き上げられていた頃は，OSS の ML で patch 添付しないでメールを送信するのは無能を表明するようなものだくらいに嗜められたように思うのですが．
恥の概念は時代の変遷により変わりますからね．トシ取りました．まだ不惑ですけれど．
で，一般論として長文での思いの丈は概ねいくつかのテンプレートに分解できます．そのなかで典型なのは「初心者に優しいサブセット提供」です．今回も出ていました．
まあ，何か解決したいっていう気持ちは判りますけれどね． μITRON4.0仕様スタンダードプロファイルに関して言えば，殆ど作る意義ないのですよ．
確かに仕様書に膨大な通信機能のAPIがあります．ですが，それらの相互依存はスタンダードプロファイル範囲では存在しません*1．使わないものは単に無視すればいいだけです．
セマフォだけしか使わないと決めればよいだけ．実際，組込みソフトウェア技術者を極めるための本をたくさん書いていてセミナーの壇上で見かけるような方々でも，控室では「開発ではセマフォくらいしか使わない」と談笑していたりします．それでよいのですよ．カーネル屋は実装するために仕様のすべてを頭に叩き込まねばなりませんが，アプリ屋さんがカーネル屋を真似する必要はありません．
POSIX系OSやWindowsで全てのサービスコールとライブラリを覚えている人は稀です．開発者は自分が使う定石を持っていて，そのなかでアプリを作ります．
これとμITRONのサービスコールの利活用は同じ構図のはずなのですが，丸暗記できそうなくらいに μITRON4.0 仕様が簡素なので，なにか誤解が生じてしまうの…かな?
などなどつらつらと考えると，JSPカーネルのコードをちまちまと弄ってもユーザは満足には到らず，デザインパターンやイディオムの欠如を補って頂く方向での努力をしたほうがよいのではないかという結論に，ワタクシ的には至ったりします．
ちなみに
「いやいや，カーネルのサイズを小さくしたくて」が云々言うのもテンプレの一つですが，これも JSPのサブセットで解決するのはスジが悪いです．
開発環境に制約がある場合を除き，JSPは libkernel.a を使おうという設計になっています．そのため，アプリがセマフォしか使っていなければセマフォしかリンクされません．制約がある場合でも semaphore.c だけリンクするようにビルド定義を替えるだけの話でしかないはず．
これはカーネルの問題というよりは，ビルド定義をどうするかという，アプリ領域の問題でしょう．
サイズを小さくしたい場合，一番ネックになるのはタスクに割り当てるスタックサイズです．μITRON4.0の自動車プロファイルのように，制約タスクを入れたり待ちを無くしたりと，抜本的な対策が必要になります．
JSPを小手先だけ弄くって解決するものではありません．本気で省メモリに挑むなら，ASPに対するSSPのような，別物を作るくらいの覚悟が要るでしょうねぇ．
というわけで
「JSPのサブセットを作れば皆使うよ」という主張には「何となく簡単になった気がする，という程度の満足しか得られませんよ」，という反論で応じたい．というお話でした．
MLに書くには長過ぎるので，日記に落としておく次第．
