未ドキュメントのハードウェア用のドライバ開発は、従来、生のバストラフィックをキャプチャし、手動でヘックスダンプを検査し、レジスタの動作に関する仮説を立てるという、忍耐強い試行錯誤に数週間から数ヶ月を要する労働集約的なプロセスでした。Christian F.K. Schallerは、ClaudeのようなAIエージェントを使用することで、この「苦行」を大幅に効率化できることを実証しました。AIモデルに数千行のUSBキャプチャデータへのアクセスを提供することで、モデルは単一のバイトが変化する繰り返しのシーケンスを特定し、それらのバイトが何を表しているかを提案し、実際のハードウェアでその発見を確認するためのテストスクリプトを生成することができます。

この手法には、正常な動作の基準を確立するための比較ハーネスの作成が含まれます。スキャナーのようにアクセス可能なバスを持つデバイスの場合、ワークフローには、仮想マシン内でベンダーのWindowsドライバを実行しながら、`usbmon`などのツールを介してホストOSからの結果的なトラフィックを記録することが含まれます。これにより、リファレンスとなるトレースが作成されます。次に、開発者はLinux上で初期段階のカスタムドライバを使用して同様の操作を実行し、2番目のトレースをキャプチャし、AIを使用してその2つを比較(diff)します。両方のトレースが同じ物理的な機器に由来するため、キャプチャされたデータにおけるいかなる不一致も、新しいドライバにおける特定のバグや欠落している機能を浮き彫りにします。

同じネガに対する2つの異なるスキャナドライバ出力の並列比較
リバースエンジニアリングのワークフローの基準を確立するために使用されたスキャナドライバ出力の比較blogs.gnome.org

この画像は、ベンダードライバとカスタムドライバを比較する比較ハーネスの手法を説明しています。

Schallerはこのアプローチを、Plustek OpticFilm 8200i用のSANEバックエンド(スキャナー用の標準的なLinuxサブシステム)の開発や、Lenovo ThinkPad X1 CarbonにおけるMIPIカメラの問題の修正など、いくつかのプロジェクトに適用しました。後者のケースでは、AIは、深刻な色収差や周辺減光を引き起こしていたカーネルレベルのクロップ選択バグや不正確なレジスタ幅の特定を支援しました。人間は物理的なハードウェアを保持し、最終的な結果を検証する責任を負い続けますが、AIはキャプチャのデコードや定数のクロスチェックという重労働を担当します。しかし、限界も残っています。実際のハードウェアテストに代わるものはありません。また、タップするための外部バスを持たない内部コンポーネントなど、INFファイル、レジストリデータ、ACPIテーブルのより複雑な検査が必要なものもあります。

AI支援による修正を適用する前後のMIPIカメラ出力の視覚的比較
Lenovo ThinkPad X1 Carbonにおけるカーネルレベルのクロップ選択バグとレジスタ幅の特定および修正の結果blogs.gnome.org

この画像は、Lenovo ThinkPad X1 Carbonのカメラに対するAI支援デバッグプロセスの具体的な結果を示しています。