TOPPERSプロジェクト成果物はカーネル実装コストを見積もることができない

昨日のエントリに対するid:monamour555さんのコメントにコメントを返そうとしながら、指が止まりました。なぜ、TOPPERS/JSP for iPhoneプロジェクトがJSPカーネルを選んだかは、私には憶測しかできませんし、そのうちわかることでしょう。
で、指が止まった時に、ふと、これまでTOPPERSプロジェクトに感じていた漠然とした印象がはっきりとした言葉になりました。

TOPPERSプロジェクト成果物はカーネル実装コストを見積もることができない.

そうそう、これがなかなか言葉にならずに喉のあたりにつかえていたのです。
たとえばTOPPERS/JSPをBlackfinに移植したとき。これはカーネルのCPU依存部をDSPに移植する、しかもツールはgccと非互換という、考えうる限り一番ハードルの高いケースだったと思います。が、実際にはドキュメントを沢山ひっくり返したり、ビルドを試したりするまで、何をしなきゃいけないのか見積もれないのです。やらなきゃいけない作業の一覧がきちんと書き表されていません。
たとえば、CPU依存部の移植ですから

  • スタートアップ・コード
  • 割り込み周り
  • コンテキスト切り替え

は、当然実装が必要でしょう。で、必然的にタイマーの部分も移植が必要とは思っていました。が、シリアルまで必要とは思っていなかったんですよ。だって、カーネルを動かすのには不要だし、MLで聞いても、必須ではないって答えが返ってきますし、なにより、ドキュメントにはシステム・ログはメモリに取っておいてもいいと書いてあります。
が、実際にはこけら落とし用のアプリケーションはべったりシリアル・ポートに依存している始末です。そりゃ書かないといけないでしょう。で、書こうとしてもシリアルがどう動いているかドキュメントなんぞありゃしません*1。ぽんとソースがそれぞれのアーキテクチャごとに置いてあるだけです。いったいどういったAPIが存在して、どんなアーキテクチャで、どのルーチンを自分が実装しなきゃいけないかなんて、皆目見当が付きやしません。
UARTのドライバの実装例はあるものの、それぞれのマイコンの中の勝手な名前になっていて、本当にUARTかどうかはよくわかりませんし、何しろ移植性なんか考慮されていないばらばらの実装です*2
挙句の果て、それらのUARTドライバを使おうとすると、PDICという公式なのか非公式なのか立ち位置のわからない規約があって、それのドキュメントを見つけてこないとシリアルの実装が面倒であることが判明。
なんかこう、いつまでたっても全貌が見えない、ってのが正直な感想でした。ドキュメントもただのテキストなので、インデックス付きのワードやPDFのような見通しの良さがありません*3。ましてツールが違うので、offset.hの扱いも七転八倒しましたし。
ASPのリリースにあたって、いろいろ改良されているらしいというのも耳に入っていますが、いったいJSPポートをASPポートに変更する場合、どの程度の差分が生じるのか、やっぱり検討がつきません。ときおりASPのページを見ていますが、JSP移植者向けのASP移植ノートもないようです。
TOPPERSプロジェクトは伽藍方式です。それ自身は別に文句を言うような筋合のことではありません。が、伽藍の中に入っていかないとわからないことが多すぎるんですよね。名古屋大学に電話を気軽に掛けられる立場じゃないと、余計な苦労が延々と続くのではないかと想像してしまいます*4
ASPに私が手を出さない理由の一つです。

*1:まったく無いというと嘘になるが、TOPPERSプロジェクトは図を嫌うので、ドキュメントが恐ろしくわかりにくい。結局自分で書いた

*2:結局UART汎用ドライバを自分で書くという滑稽劇

*3:結局自分でインデックス付きドキュメントを生成した

*4:ついでに言うと、経験的にこの伽藍はお布施を払って中に入らない限り、外からの寄与も受け付けない