我目前正在使用gdb（see this setup guide）设置vmware Server 2.0进行内核调试，有人问我为什么不使用kvm？
所以我问：kvm vs. vmware用于内核调试/ USB驱动程序开发
各自的优点和缺点是什么？
答案 0 :(得分：1)
驱动程序开发？你在为一个特定的硬件工作吗？如果是这样，那么您可能无法使用虚拟化，因为虚拟化实例将无法访问新硬件。
为此，您需要两台计算机，一台运行远程调试器，另一台运行远程调试器。
*编辑：* 显然您正在为USB设备开发驱动程序？这是一个特别是虚拟机实际可以提供帮助的领域。目前，大多数VM都能够将特定的USB设备委派给客户操作系统。
也就是说，这种情况并没有提供远远超过远程调试器选项的任何好处，因为您仍然需要一种方法来检查正在运行或崩溃的操作系统的状态，而VM在这方面提供的帮助很少。您可以在崩溃之前重播已保存的状态。
您可以使用UML获得一些牵引力，这可以让您像常规用户进程一样进行本地调试，这样可以减少麻烦。
答案 1 :(得分：0)
我没有回答直接问题，而是添加另一个选项......根据所讨论的内核是否是Linux内核，以及您正在处理的内容，您可能会发现UserModeLinux（包括在2.6.x源代码中，可用作2.4和2.2的补丁集可能胜过这两个选项。
由于它在主机内核下作为用户空间进程运行内核，因此更容易将常用调试工具附加到。我相信它在文件系统相关代码的更新/添加的早期阶段非常常用。如果您正在开发/调试与硬件直接交互的模块，那么对您的使用可能会少得多。
答案 2 :(得分：0)
我最近开始构建GNU Mach / HURD并发现QEmu / KVM的组合非常好用......出于以下原因：
底线是，对于内核工作，我只想要最少的功能来启动并查看结果。 VMWare更适用于可用的虚拟化，而不是简单易用。
然而，在使用真实硬件的真实计算机上启动无比较。 VM环境看起来像是安全毯......因为即使我的烤面包机也会知道Realtek RTL8139C是什么。
答案 3 :(得分：0)
如果它是“真正的硬件”设备，当然vmware不会模拟它，所以你将无法调试它下面的驱动程序（任何其他虚拟化软件也不会，除非你扩展一个这样做）。
设备驱动程序调试可以在一定程度上使用具有普通内核的真实硬件机器完成 - 尽管显然有些事情是你做不到的 - 比如设置断点。
仍然可以将调试器附加到内核并检查内容。而且，传统的printf（）调试很有可能（printk，任何人），并且内核中有各种功能使调试更容易。可以使用各种调试选项构建内核，以尝试检测指针问题，内存泄漏等。
默认情况下，内核在遇到OOPS或BUG条件时甚至会在日志上提供一个很好的堆栈跟踪（显然，如果系统挂起或崩溃，这不一定会写在任何地方）。当然，在中断内发生指针超出范围的情况是一个灾难的处方，但你仍然可以在恐慌之前立即在屏幕上获得堆栈跟踪：）