TOPPERSにおけるカーネルの位置づけと，コンフィギュレーションの件
TwitterのTLとか巡回先のコメントとかを見て．ああ，なんというか，伝わっていないなぁというか．
組織として，この手の素朴な疑問についてカジュアルに答えられる人材が育たなかったのは，中長期的に大きく効いてくる気がしますが，それを心配するだけの立場でも無し．淡々と自説展開しますよ．
もしかしたら私だけがワケワカラン解釈をしているのかもしれないので，信じるかどうか，参考にするかどうかは，読者責任．
「RTOSカーネルはCPUのためのデバイスドライバである．」
「RTOSカーネルはCPUのためのデバイスドライバである．」という考え方の妥当性については知りません*1．違う見方もあるでしょう．ただし，この見方は，μITRON4.0仕様ならびにTOPPERSカーネル群の事実上の産みの親である名古屋大学の高田教授が，一時期好んで使っていた表現です．最近はそういう表現を使っている場面に立会いませんが，根底にこの視点がある(もしくはあった)ことは理解する必要があります．
TOPPERSのコンフィギュレータは，略さずに言うと，カーネルコンフィギュレータである
コンフィギュレータって略すから，なんでもしてくれそうな気になります．
μITRON準拠系のTOPPERSカーネルの cfg/ 辺りにあるのは，カーネルコンフィギュレータです．つまり，RTOSと言う名の"CPUのためのデバイスドライバ"のコンフィギュレーションしか考慮されていません．
現に，より抽象度の高いミドルウェアであるTINETは，独自のコンフィギュレータを持っています．理想的/空想的には，全てのデバイスドライバ/ミドルウェアは，独自のコンフィギュレータを持つべきです．現実との折り合いを捨て去ることはできません．しかし少なくとも理念的には，そうなります．これは，μITRON仕様の発展形であるTOPPERS統合仕様で否定されていませんので，同様です．
だから，現状のTOPPERS新世代カーネルにあるコンフィギュレータには問題がない
だって，CPUに極めて近い部分(カーネル)のコンフィギュレーションしか考慮していませんから．
「CPUって，どこまで?」という根源的な問いはμITRON仕様には常に降りかかっていて，割込み周りはCPUではないという*2μITRON4.0仕様に基づきつつも割り込み周りを分離しきれなかったTOPPERS/JSPでは，割り込みベクタが実質的には動的書換不可な環境*3でツールによるhackで辛うじて仕様に準拠しています．
TOPPERS/ASP では，上記のような揺れを排除すべく，割込みに関する標準モデルを打ち立てました．このおかげでターゲット依存部の移植が苦しくなったという意見も耳にします．しかしそれは，ターゲット依存部の移植者が，エンドユーザに丸投げしていた苦しみを自ら引き受けるようになったっていうことです． 進化として諦めて頂くか，JSPを採用してエンドユーザに再び苦しんでいただくほかはないでしょう．
ここで，TOPPERS新世代カーネルでも，タイマと割り込みコントローラをCPUの一部として認めたに過ぎず，その他のペリフェラルはRTOSの範囲外と(暗に)みなしていることに注目する必要があります．
よって，デバイス用(もしくはボード用)のコンフィギュレータが要る
おそらく勘の良い方は気づいていらっしゃるでしょうけれども，TOPPERSカーネルに足りないのは，コンフィギュレータの機能拡張ではありません．コンフィギュレータはフレームワークです．TOPPERSカーネルに標準で付いているのは，フレームワークとしてのコンフィギュレータをカーネルに適用しただけのものです．
カーネル以外でユーザのコンフィギューレションを許すものがあるとするならば，ソフトウェアコンポーネントの単位毎に独自のコンフィギュレーションスキームを，フレームワーク上に構築することが期待されます．先に挙げたTINETのように．(少なくとも理念的には)
で，どうすべきなの?
とは言っても，仮にフレームワークライブラリが存在していても，そのような複雑な環境の構築を，週末の電子工作の範囲で行うのは無理です．仕事でも，有るものを使うのはアリかもしれませんが，デバドラ作る上にこんな作業するのは避けたいところです．
TECSがこれを担うことが期待されましたが，崇高なところに行ってしまい，しばらくは帰ってきそうにありません．
twitter 上では「カーネルオブジェクトが動的IDに対応すれば」という指摘もありました．確かに一定のレイヤで何かを楽にすることはあるかもしれませんが，コンフィギュレーションの問題を解決するものではありません*4．
Webアプリケーション上における JavaScript と CoffeeScript の関係のように，簡単な記述で複雑なコンフィギュレーションファイルを作成できるような環境を作るのは一つの方法でしょう．
また，もっと割りきって，設定情報マクロを含むインクルードファイルを生成するための，UIを簡単に構築するということも有り得るでしょう．Androidアプリ作成における，preferences.xml のようなものがあれば，デバドラ作成者が協力してくれることもあるでしょう．
で，どうなるの?
というわけで，設計思想的にどうなのか，対策として何がありえるのか，私見の範囲で述べました．
「将来的に，どうなるのか」という問いには答えません．コの業界で将来を予測するのは，天才かペテン師，どちらかしか居ませんので．
