僕の職歴2

bootloaderの開発が一段落したころ、無線LANチップそのものを開発とする話がありました。無線LANチップの中には実は小さなCPUが入っていて、そのCPU上で動作するプログラムを書くという案件です。やったことがない仕事をするのが大好きだったので、一にも二にもなくとびつきました。

まずAtherosのホスト側ドライバのソースコードが公開されていたので、それを読んで気になるところをメモしました。その後できあがってきたプロトタイプのでっかいボードの起動確認をしたりしていたのですが、他業務と並行で工数調整をしながら進める能力がかけていて、途中で戦力外通告されてしまいました。プロジェクトに大変迷惑をかけましたが、安易に仕事を引き受けてはいけないという良い経験になりました。

そうこうしている内に新製品のBIOSのメーカを既存製品と違う会社にしようという案件がもちあがりました。英語が苦手でしょうがなかったのですが、米国東海岸に行って身振り手振りでOSサイドからBIOSへの要求項目を説明したら1週間程度である程度動作するBIOSを作ってくれました。あの時ぼくのつたない英語力を使う機会をくれたKさんには感謝しています。

その後にアサインされたのは巨大な組込みシステムの起動時間を10秒にする、というプロジェクトでした。この10秒というのはkernelの起動だけではなく、BIOS=>OS=>アプリ=>画面表示の全てを10秒におさえなければなりません。まず最初に左記の起動シーケンスを横断で測定できる簡単なツールを開発しました。これで、測定にかかる手間を一気に削減できました。その後、各ステージでかかっている時間が長いものから順番に削減検討しました。本来は各アプリの開発担当を呼んで、削減依頼をかけるべきです。しかし、IPCでからみあった起動シーケンスは定常状態とは異なり、1アプリの中だけで完結しません。アプリAの処理に時間がかかっているのは、アプリBの処理待ちで、さらにアプリBはディスクのmountを待っている、ようなことが多発していた訳です。そこで、一旦一人で起動ログを横時間軸の散布図にして、ギャップの大きい部分にしぼり、その処理待ち合わせの依存を解析しました。その解析結果もってアプリの修正をコンサルタントするようにしました。

このような方法を取ったのですが、それでも10秒を達成するのは困難でした。ディスクの読み込みに時間がかかっていたためです。そこで、アプリを画面表示に必須なものと、そうでないものの二種類に分けて、前者のみをディスクから読み込み/起動、後者は画面表示が完了してから読み込むようにしました。この方法で10秒起動を達成できたのですが、アプリのIPC接続関係が変動するとバグを引き起こすという諸刃の剣です。当然、機種が出る度になんらかの障害を引き起こしてしまうことになりました。もっと良い方法がなかったのか、今でも悩むことがあります。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中