μT-Kernel仕様を読んでみた．

仕様書は閲覧可能なので，ざっと斜め読みしてみた．

各オブジェクトにdsnameなるデバッグ用の文字列を与えたり，静的なオブジェクト生成が無かったり，RAMがたっぷりある環境を想定しているっぽい．ARMだとPhilipsやADIは捨て．ルネサスだとR8Cは完全に捨て．NECならV850ESの上位ラインナップなら辛うじてOK．てな案配．

率直な感想

仕様は順当．μITRON3.0仕様に立ち戻り，μITRON4.0で特徴的な要素をいくつか潰せば，こういう仕様になる．
こんなにRAMがある環境ばかりではないとは思う．でもTOPPERSで言えばFI4の世界に相当するわけだ．
ROMもたっぷり消費するのだから，見合うRAMを期待する，というのは論理として判らなくもない．

純粋に技術者視点で見ると，順当．しかし，このタイミングでこの仕様を出す戦略の意図が良く判らない．
組込みBTRONで闘いに挑んでLinuxに負け，スケールを落として活路を見出そうというのだろうか．でもこのカーネル仕様のスケールだと，μCLinuxの一番小規模な部類とニアミスする．ファイルシステムやTCP/IPスタックは欲しいとなれば，バッチリ重なりそうだ．

世間が心配するような(そして私が心配したような)TOPPERSとの競合はしそうにない．
確かに，μITRON4.0仕様のミューテックスを取り入れるなど，APIセットだけ見れば重なるのだけれども，静的APIの有無は，RAM使用量や検証可能性といった，組込みで一番気にするところに関して，決定的に効いてくる．
OSEKの仕様が(実際に使っている人が小数でも，教養的知識として)一般に知られるようになった結果，静的なカーネルコンフィギュレーションに違和感を感じる人は少なくなってきている．特に，組込み業界での当面のドル箱と目されている車載関係はそうだ．

まあ，シェアがフラグメントした組込みの世界．μT-Kernelにもシェアに食い込む余地が無いとは思わない．μITRON3.0を使っていて，そろそろ乗り換えを考えているという場合には，考え方が似通っているμT-Kernelのほうが，(仕様上の直系であるμITRON4.0系よりも)移行しやすい可能性はある．でも，そのパイの数は，T-Engineフォーラムの規模を考えると，必ずしも大きいとはいえない．

私の想像を超える壮大な計画の布石なのか，それとも，T-Kernel仕様に引っ張られた中途半端な仕様のままで甘んじるのか，しばらく静観が必要かもしれない．