ナビゲーションリンクをスキップ | |
印刷ビューの終了 | |
デバイスドライバの記述 Oracle Solaris 11.1 Information Library (日本語) |
パート I Oracle Solaris プラットフォーム用デバイスドライバの設計
2. Oracle Solaris カーネルとデバイスツリー
22. ドライバのコンパイル、ロード、パッケージ化、およびテスト
23. デバイスドライバのデバッグ、テスト、およびチューニング
デバイスドライバが機能するようになったら、配布前にそのドライバを完全にテストする必要があります。従来の UNIX デバイスドライバに備わる機能をテストするほかに、Oracle Solaris ドライバでは、ドライバの動的なロードとアンロードなどの電源管理機能もテストする必要があります。
複数のデバイス構成を扱うドライバの機能は、テストプロセスの重要な部分です。ドライバが単純な構成やデフォルトの構成で機能するようになったら、追加の構成をテストする必要があります。デバイスによっては、ジャンパーまたは DIP スイッチを変更することで構成のテストを完了できます。可能な構成の数が少ない場合は、すべての構成を試してください。数が多い場合は、可能な構成から成るさまざまなクラスを定義し、各クラスからサンプリングした構成をテストする必要があります。これらのクラスの定義は、異なる構成パラメータ間でどれだけの対話が可能かに左右されます。これらの対話はデバイスの種類と、ドライバが記述された方法との相関関係です。
デバイス構成ごとに、基本の機能をテストする必要があります。それには、デバイスをロードする、開く、読み取る、書き込む、閉じる、アンロードする機能が含まれます。構成に依存するすべての機能には特に注意を払う必要があります。たとえば、デバイスレジスタのベースメモリーアドレスを変更することは、おそらくほとんどのドライバ機能の動作には影響を与えません。ドライバが 1 つのアドレスで正常に機能する場合、そのドライバはおそらく、異なるアドレスでも機能します。一方、特別な入出力制御呼び出しでは、特定のデバイス構成に応じて効果が異なる可能性があります。
さまざまな構成でドライバをロードすることで、probe(9E) および attach(9E) のエントリポイントが異なるアドレスで確実にデバイスを見つけることができます。基本機能のテストの場合、文字デバイスについては、cat(1) や dd(1M) などの通常の UNIX コマンドを使えば通常は十分です。ブロックデバイスについては、マウントやブートが必要な場合があります。
ドライバの構成を完全にテストしたら、ドライバのすべての機能を完全にテストする必要があります。これらのテストでは、ドライバのすべてのエントリポイントの操作を実行する必要があります。
多くのドライバには、機能をテストするためのカスタムアプリケーションが必要です。ただし、ディスク、テープ、非同期ボードなどのデバイスの基本ドライバは、標準のシステムユーティリティーを使用するとテストできます。このプロセスでは、該当する場合は devmap(9E)、chpoll(9E)、ioctl(9E) を含むすべてのエントリポイントをテストするようにしてください。ioctl() テストは、ドライバごとに大きく異なる可能性があります。標準でないデバイスでは、通常はカスタムテストアプリケーションが必要です。
ドライバは理想的な環境では正常に実行されても、間違った操作や正しくないデータなどのエラーがある場合は失敗することがあります。そのため、ドライバのエラー処理のテストが、ドライバのテストの重要な一部となっています。
実際のハードウェアの誤動作に関するエラーの条件を含めて、ドライバの考えられるすべてのエラー条件を与える必要があります。一部のハードウェアエラー条件は発生させるのが困難な場合がありますが、可能であれば、そうしたエラーを強制したりシミュレートしたりするように努める必要があります。これらの条件は、実地ではすべて発生する可能性があります。ケーブルを抜いたりゆるめたり、ボードを取り外したり、エラーのあるユーザーアプリケーションコードを記述したりして、そうしたエラーパスをテストする必要があります。第 13 章Oracle Solaris ドライバの強化も参照してください。
注意 - テスト時には電気的に適切な対策をとるようにしてください。 |
ロードまたはアンロードされないドライバは予定外の停止時間の原因となるため、ロートとアンロードは完全にテストしておく必要があります。
次の例のようなスクリプトで十分です。
#!/bin/sh cd <location_of_driver> while [ 1 ] do modunload -i 'modinfo | grep " <driver_name> " | cut -cl-3' & modload <driver_name> & done
ドライバのパフォーマンスを確保する助けになるように、ドライバには厳しいストレステストを適用する必要があります。For example, running single threads through a driver does not test locking logic or conditional variables that have to wait. いくつかのスレッドで同じコードを同時に実行させるには、複数のプロセスで同時にデバイスの操作を実行する必要があります。
同時テストを実行するための手法はドライバによってさまざまです。一部のドライバでは特殊なテストアプリケーションが必要ですが、その他のドライバでは、バックグラウンドでいくつかの UNIX コマンドを開始すれば十分です。どのようなテストが適切であるかは、各ドライバでロックと条件変数が使われている場所によって異なります。マルチプロセッサマシンでドライバをテストすると、シングルプロセッサマシンでテストする場合より問題が表面化する可能性が高くなります。
ドライバ間の相互運用性もテストする必要があります。これは特に、さまざまなデバイスが割り込みレベルを共有できるためです。可能であれば、1 つのドライバをテストしているときに、別のデバイスを同じ割り込みレベルで構成します。ストレステストを行うと、ドライバが自身の割り込みを正しく要求し、予測どおりに動作するかどうかを判断できます。ストレステストは両方のデバイスで一度に実行する必要があります。デバイスが割り込みレベルを共有していない場合でも、このテストは有用です。たとえば、ネットワークドライバのテスト時に、シリアル通信デバイスでエラーが発生している場合を考えてください。同じ問題が原因で、システムの残りの部分でも割り込みの待ち時間の問題が発生することもあります。
これらのストレステストを適用したドライバのパフォーマンスは、UNIX のパフォーマンス測定ツールを使用して測定してください。この種類のテストは簡単で、time(1) コマンドを、ストレステストで使用されるコマンドとともに使用するだけで実行できます。
後のリリースとの互換性と、最新リリースに対する信頼できるサポートを保証するため、すべてのドライバを DDI/DKI 準拠にする必要があります。『man pages section 9: DDI and DKI Kernel Functions 』および『man pages section 9: DDI and DKI Driver Entry Points 』のカーネルルーチンと、『man pages section 9: DDI and DKI Properties and Data Structures 』のデータ構造体のみが使用されていることを確認します。
ドライバはお客様に、パッケージで提供されます。システムに対するパッケージの追加または削除は、標準のメカニズムを使って行えます。ユーザーがシステムに対してパッケージの追加や削除を行う機能をテストする必要があります。テストでは、パッケージのインストールとアンインストールの両方を、pkg install コマンドと pkg uninstall コマンドを直接使って行うようにしてください。詳細は、『Oracle Solaris 11.1 ソフトウェアパッケージの追加および更新』を参照してください。
このセクションでは、特定の種類の標準デバイスをテストする方法について、いくつかの提案を示します。
テープドライバは、保管と復元のいくつかの操作を実行してテストする必要があります。この目的のために、cpio(1) コマンドと tar(1) コマンドを使用できます。ディスクパーティション全体をテープに書き込むには、dd(1M) コマンドを使用します。次に、データを読み戻して、同じサイズの別のパーティションにデータを書き込みます。その後、2 つのコピーを比較します。mt(1) コマンドは、テープドライバ固有の入出力制御の大半を実行できます。mtio(7I) のマニュアルページを参照してください。すべてのオプションを使用してみます。次の 3 つの手法で、テープドライバのエラー処理機能をテストできます。
テープを取り出し、さまざまな操作を試みる
テープを書き込み保護にして書き込みを試みる
さまざまな操作の途中で電源をオフにする
テープドライバは、通常、排他的アクセスの open(9E) 呼び出しを実装しています。これらの open() 呼び出しは、デバイスを開き、2 番目のプロセスで同じデバイスを開こうとすることでテストできます。
ディスクドライバは raw モードとブロックデバイスモードの両方でテストする必要があります。ブロックデバイステストの場合、デバイス上に新しいファイルシステムを作成します。次に、新しいファイルシステムのマウントを試みます。次に、複数ファイルの操作を実行してみます。
注 - ファイルシステムはページキャッシュを使用するので、同じファイルを繰り返し読み取ってもドライバを働かせることになりません。ページキャッシュは、mmap(2) を使用してファイルをメモリーマッピングすることで、デバイスからデータを取得するように設定できます。次に msync(3C) を使用して、メモリー内のコピーを無効にします。
同じサイズの別の (マウントされていない) パーティションを raw デバイスにコピーします。次に、fsck(1M) などのコマンドを使用して、コピーが正しいことを検証します。新しいパーティションもマウントし、あとで古いパーティションとファイル単位で比較できます。
非同期ドライバは、シリアルポートへの login 用の回線を設けることで、基本レベルでテストできます。ユーザーがこの回線でログインできるかどうかを確認するのが適切なテストです。ただし非同期ドライバを十分にテストするには、割り込みを多数発生させて、すべての入出力制御関数を高速でテストする必要があります。ループバックシリアルケーブルを使用し、高速なデータ転送速度でテストを行うと、ドライバの信頼性を判断する助けになります。回線上で uucp(1C) を実行すると、一部のテストを行えます。ただし、uucp は独自のエラー処理を実行するため、ドライバが uucp プロセスに報告するエラーの数が多すぎないか検証してください。
これらの種類のデバイスは、通常、STREAMS ベースのデバイスです。詳細については、『STREAMS Programming Guide 』を参照してください。
ネットワークドライバは標準のネットワークユーティリティーを使用するとテストできます。ネットワークのそれぞれの側でファイルを比較できるため、ftp(1) コマンドと rcp(1) コマンドが役立ちます。ドライバは高いネットワーク負荷をかけてテストする必要があるため、複数のプロセスで多様なコマンドを実行できます。
高いネットワーク負荷に該当するのは、次のような条件です。
テストマシンへのトラフィックが非常に多い。
ネットワーク上のすべてのマシン間のトラフィックが非常に多い。
テストの実行中にネットワークケーブルを抜き、発生したエラー状態から正常に回復することを確認する必要があります。別の重要なテストは、複数のパケットをドライバにたて続けに受信させることです。つまり、連続パケットを使用します。この場合、比較的高速なホストを負荷の少ないネットワーク上に置き、複数のパケットを間断なくテストマシンに送信します。受信側のドライバで、2 つ目以降のパケットが欠落していないことを確認します。
これらの種類のデバイスは、通常、STREAMS ベースのデバイスです。詳細については、『STREAMS Programming Guide 』を参照してください。
SR-IOV をサポートするドライバでは追加のテストを行う必要があります。標準の基本的なテストも必要となりますが、ネットワークデバイス用の ftp や rcp など、基本的なテストで使用されるユーティリティーを使用できます。
SR-IOV ドライバについては、第 21 章SR-IOV ドライバを参照してください。
仮想機能 (VF) のステータスをテストするには、次のコマンドを使用します。
有効化された VF – hotplug install
無効化された VF – hotplug uninstall
割り当て済みの VF – hotplug list
SPARC システム上で VF のステータスをテストする場合、hotplug コマンドのほかに ldm(1M) コマンドも使用します。
また、さまざまな仮想化構成で SR-IOV デバイスをテストすることも重要です。SPARC と x86 の両プラットフォームで SR-IOV ドライバのテストを行う際は、次のオプションを試してください。
仮想機能 (VF) を一切構成しません
VF を 1 つだけ構成します
VF の最大数に達するまで、構成された VF を 2 の累乗ずつ増やします
SPARC プラットフォームでは、さまざまな数の IO ドメインを使用し、それらのドメイン内で VF をさまざまに分散させて、機能をテストします。次の構成を試してください。
単一の IO ドメインに単一の VF を割り当てます
単一の IO ドメインに 2 の累乗個の VF (最大数まで) を割り当てます
2、4、または 8 個の IO ドメインを作成し、それぞれのドメインにさまざまな数の VF を割り当てます
ルートドメインにいくつかの VF を割り当て、IO ドメインにもいくつかの VF を割り当てます
デバイスまたはプラットフォームが次の機能をサポートしている場合は、それらのテストを行います。
VF から IO ドメインをブートします
SR-IOV カードを物理的にホットプラグしたり取り外したりします
SR-IOV カードで動的再構成処理を実行します
デバイスが Oracle Solaris の複数のバージョンでサポートされている場合、最終的なテストを実行するには、いくつかのテストでルートおよび IO ドメイン全体で OS バージョンを混在させます。