現在、gdb を使用したカーネル デバッグ用に vmware Server 2.0 をセットアップしています (このセットアップ ガイドを参照)。
だから私は尋ねます：カーネルデバッグ/ USBドライバー開発のためのkvm対vmware
それぞれの長所と短所は何ですか？
1878 次
4 に答える
1
ドライバー育成？特定のハードウェア用のドライバーを開発中ですか? その場合、仮想化されたインスタンスは新しいハードウェアにアクセスできないため、仮想化を使用できない可能性があります。
このためには、2 台のマシンが必要です。一方はリモート デバッガーを実行し、もう一方はリモート デバッガーを実行します。
*編集: * USB デバイス用のドライバーを開発しているようですね。これは、特に VM が実際に役立つ領域の 1 つです。最近のほとんどの VM には、特定の USB デバイスをゲスト OS に委任する機能があります。
とは言うものの、この状況は、リモート デバッガー オプションに勝るメリットはありません。実行中またはクラッシュした OS の状態を検査する方法が依然として必要であり、VM はこの点に関してほとんど支援を提供しないためです。クラッシュの直前から保存された状態を再生できる場合があります。
UML を使用すると、通常のユーザー プロセスと同じようにローカル デバッグを実行できるようになり、問題が少し軽減される可能性があります。
于 2009-06-21T09:34:27.910 に答える
0
直接の質問に答える代わりに、別のオプションを追加します... 問題のカーネルが Linux カーネルであるかどうか、およびそのカーネルのどの部分に取り組んでいるかによって、UserModeLinux (2.6 に含まれる.x ソース、および 2.4 と 2.2 のパッチ セットとして利用可能) は、これらのオプションの両方に勝る可能性があります。
ホストカーネルの下でカーネルをユーザーランドプロセスとして実行するため、一般的なデバッグツールを簡単に接続できます。ファイルシステム関連のコードへの更新/追加の初期段階で非常に一般的に使用されていると思います。ハードウェアと直接やり取りするモジュールを開発/デバッグしている場合は、あまり役に立たないかもしれません。
于 2009-06-21T09:27:47.190 に答える
0
私は最近、GNU Mach/HURD の構築を開始し、QEmu/KVM の組み合わせが非常にうまく機能することを発見しました..次の理由から:
- QEmu は非常にクリーンな環境を提供します
- ネットワークには多くのオプションがあります
- rawデバイスファイル/ループバックを使用してファイルシステムを簡単にマウントできます
要するに、カーネルの作業では、最小限の機能を起動して結果を確認したいだけです。VMWare は、ダウン アンド ダーティではなく、使用可能な仮想化のためのものです。
ただし、実際のハードウェアを備えた実際のマシンでの起動とは比較になりません。VM 環境は、ときどき安全毛布のように見えることがあります。私のトースターでさえ、Realtek RTL8139C が何であるかを知っているからです。
于 2009-06-21T10:11:49.037 に答える
0
もちろん、それが「実際のハードウェア」デバイスである場合、vmware はそれをエミュレートしないため、その下でドライバーをデバッグすることはできません (また、そうするように拡張しない限り、他の仮想化ソフトウェアも同様です)。
デバイス ドライバーのデバッグは、通常のカーネルを備えた実際のハードウェア マシンを使用してある程度行うことができますが、ブレークポイントの設定など、明らかにできないことがあります。
デバッガーをカーネルに接続して検査することは引き続き可能です。さらに、従来の printf() デバッグは非常に可能であり (printk、誰でも)、カーネルにはデバッグを容易にするさまざまな機能があります。さまざまなデバッグ オプションを使用してカーネルをビルドし、ポインターの問題やメモリ リークなどを検出することができます。
デフォルトでは、カーネルは OOPS または BUG 状態に遭遇したときにログに素敵なスタック トレースを出力します (明らかに、システムがハングまたはクラッシュした場合、これは必ずしもどこにも書き込まれるわけではありません)。もちろん、割り込み内でポインターが範囲外の状態になると、大惨事になりますが、パニックの直前に画面にスタック トレースが表示される可能性があります :)
于 2009-06-21T10:47:11.103 に答える