携帯電話をオープンな形で開発可能にしようというのには、まだまだ解決すべきテーマが山積しているようだ。このテーマを列挙するだけでもビジネスの芽や特許の萌芽があるかもしれない。何も感じないという人には戯言にしか映らないだろうけれど、まあ世の中そんなものである。ひらめきを大切にしないと世の中に自分とそっくりの人間が三人いると言われているのと同様に、同時期に同じアイデアにたどり着く人間は必ずいるのである。行動しないでいるのは、大きな損なのではあるが、地動説を説くような事態にあっては個人で申請する以外に会社側でも特許など受け付けてくれないかもしれない。それでも特許は出すべきであろう。

テーマの一つには実機で行うデバッグが挙げられる。当たり前のようにJTAGを使えば簡単な話だというなかれ。確かに現在のチップセットだけでみればJTAGでデバッグしてしまえば簡単であり、問題はそうした形態であっても機体番号などの情報の書き換えや読み出しを出来ないような形にしてほしいというのが通信キャリアの考える実機でのデバッグなのである。アプリケーション開発のみに終始するようなベンチャー達と業務を運用する世界とを分離したいというのがテーマの背景にあるからだ。そうして現在供給されている多くのアプリケーション開発環境自体はPCなどでエミュレーションするものであり中々実機での確認との間の差異を埋めるのに難しいからでもある。また、メーカーの多くが今までは開発してきたブレッドボードのような物をベースに供給するには環境構築の費用が折り合わないからでもある。

矛盾するようだが、通信キャリアは自身が提供する特殊通信仕様に従って内部情報については自由に書き換えが出来なければならないという機能がある。これが出来なければ、端末切り替えなどでショップで容易に書き換えなどが出来ないからでもある。そういう事情もあり、端末コネクタから容易にデバッグするという以前にシリアルインタフェースの公開すら難しいという事情も見え隠れするのである。であれば、やはりPCのみで開発させるのが理想的な姿なのかと、仮想携帯のハードウェアをPC上に構築してVMwareのような形でエミュレーションしつつ実機とのバランスをとるというやり方もあるだろう。実機での動作でのモデム部分のオーバーヘッドなどの処理も含めた部分については難しいということになってしまいそうだ。

もう少し考え方を変えるとドライバ処理のみを実機に行わせてアプリケーション自体をPC側でAPIチェックを行いつつリモートで行わせるという考え方がありえそうだ。表示速度などの部分の確認は実機で行いつつ、アプリケーションの検証と言った意味でのオーバーヘッドなどはPC側の高速な環境で実現して安心を勝ち取るということになる。鍵となるのは高速な通信機能の実現であり、アプリケーションデバッグに根ざしたエージェントとの通信機能で利用可能なJTAG通信機能などが必要とされるのだろう。かつてアプリケーションプロセッサの実現検証の過程でシリアルベースのRPCが実装されたと聞くのだが昨今のマルチメディアな実装を果そうとしている上には難しい技術なのかもしれない。

まあ時代はARM9やARM11クラスにシフトしようとしているので、UNIXのptraceの実現と同様なプロテクトされた形でのデバッグ機能の実現も可能になってくると思われるのだ。規定外のアクセスなどについての違反検知といった機能も含めて実機で実現することが可能になってくるかもしれない。MMUとOSのサポートも含めて考えることに徹すれば、そろそろ実現が難しくないのがこの方法論だろう、やはり有用なELFファイルなどからのシンボルファイルの取り扱いが出来れば実現しそうな匂いがしてくる。しかし、現実を阻むのはシステム検証している際に担当の異なるソフトウェア同士の機能コンフリクトなどの問題についてデバッグ管理をどのようにするのかという点になってきそうだ。

おまえが悪い、誰が悪いとリアルタイムトレースよろしく開発していく上での話には、ＥＴＭが技術的には登場しているものの、実はそれ以前に当たりをつけていくという目的にあっては異なったアプリケーションあるいはドライバーの担当者が一同に会してデバッグしていくということが必要なのだが、生憎とデバッグコンソールに仕掛けられる情報が制限されてしまうのはフラッシュの上でのデバッグゆえかJTAGのハードウェアブレークでは機能が足りないのである。まあ、すでに時代はDRAM実装に向かっているので問題はないということかもしれない、ソフトウェア屋さんの意見が製品設計に反映しているのならば是非NANDとDRAMの組み合わせで開発して欲しいものである。

いや待てよ、オープンな開発という観点に立てば、デバッグしている場所はどこかに固定しているとしても担当しているソフトハウスは皆、日参してデバッグしなければならないのか・・・。スクリーンシェアという観点に技術を置けばリモートでデバッグすることも可能な時代になっているので、光ファイバの時代でもあり現在では何の足かせにもならないようだ。でも端末メーカー内部には、そんなインフラスペースは無いのもしれない。まあ、こんな世界でも最もFTTH費用が安い日本だから通信費用も速度も足かせにはならないようだ。それに端末メーカーはBIOS提供しか行わなくなるだろうから、きっとデバッグスタジオ自体は通信キャリアか、サービスベンダーになっているはずだから・・・。そうかそれなら出来そうな気がしてくる。でも複数の会社の担当者が全員で関係ないソースコードも含めたブレークポイントやデバッグコンソールにかかりっきりになっていたら使いものにならないのかも・・・。

一つの鍵は、同時に複数のデバッグコンソールを一つのデバッグエージェントに対して行えれば解決するわけだ。誰か開発していそうな技術のような気がするんだが、通信キャリアも含めて新しいオープンなソフトウェア開発の一歩は踏み出せそうな気がして来るのは実感なんだけれども、なぜか足らないと感じるのは端末メーカーからのエールが聞こえてこないんだよね。鶏と卵の議論になってくるのかもしれないけれどソリューション提示する立場の会社が技術ベンチャーと組んでそうした技術や通信キャリアとのビジネススタイルの刷新を提言していくようなことが出来る時代にならなければいけないんだろうな。端末開発の課題であるソフトウェア開発コストを削減していくためには、要求されるコストを実現するようなビジネススタイルやそれに必要な技術開発をしていく必要があると思うんだけれどもね。