軟弱者として、私は現在、ハードウェア検出メカニズムに関するハードウェア技術者と戦っています。
現在構築されている検出ソフトウェアが、将来開発されるすべてのハードウェア バージョンの限定された一連のプロパティを認識できるように、「将来を保証する」検出/発見メカニズムを構築することが可能であるべきだと思います。 .
反対意見: 現在の (dsp) チップは近い将来時代遅れになるかもしれません。したがって、将来のボードが現在の検出プロトコルと互換性があることを保証することはできません。
これは USB や PnP などでどのように行われますか? 他の例はありますか?
あなたがほのめかしているように、答えの鍵はプロトコルにあります。常に美しいとは限らず、デザインに縛られていることもあります。
ただし、PC アーキテクチャ自体が、前方検出の実現可能性を証明しています。
たとえば 1996 年にコンパイルされた Linux カーネルを、今日購入したシステムで完全に起動できることがよくあります。Linux システムは、そのシステム内のハードウェアの多くを使用できない場合がありますが、サブセットがまだ同じであることを検出します。
ただし、非常に賢明なハードウェア検出スキームか、クラッジを受け入れる意欲 (PC での A20 のセットアップを参照してください。元々はキーボード コントローラーを使用していました)、またはその両方が同時に必要です。(今日のほぼすべての PC が、PS/2 キーボードのサポートなどのために内部に古い ISA バスを備えているのと同様に、PCI プロトコルも備えています。)
仕事のために、ドーターボード用の ID ROM フォーマットを設計しました。それらは、いくつかの必須フィールド、いくつかのオプション、およびバージョン番号を備えた、コンパクトなバイナリ XML または Lisp のような構造を持っていました。完全に新しいハードウェアは、バージョン番号をインクリメントし、新しいソフトウェアに必要なデータを追加できますが、古いフィールドで適切なものを古いソフトウェアに伝えます。
少なくとも、古いソフトウェアがボード ID と目的を検出して、あきらめることができるようにするためです。これは、USB デバイスがどのように機能するかです。すべての古いソフトウェアは新しいデバイスを列挙できますが、古いソフトウェアが意味のある方法で新しいハードウェアを駆動できるかどうかは確実ではありません。例外はキーボード、マウス、メモリー スティックで、誰もが古い「アプリケーション レベル」、いわばプロトコルに固執しています。
標準的な方法で OS に送信される設定可能なベンダー ID とデバイス ID があります。それを担当するドライバーは、この方法でハードウェアを認識します。したがって、ドライバーでデバイス ID がわかっている場合は、互換性があるかどうかがわかります。デバイス ID が変わらない場合は、ハードウェア デザインのバージョンなどの追加情報 (推奨) を格納するために読み取ることができるメモリ マップド レジスタを使用する必要があります。
いずれにせよ、ドライバーはどのハードウェアと通信しているかを認識し、それに応じて反応する必要があります。ハードウェアを正しく検出するための標準的な方法を用意することは、設計上の問題です。したがって、この情報が保存されているいくつかのアドレスに同意し、それに固執してください。また、将来拡張できるように設計します。