我目前正在设置 vmware Server 2.0 以使用 gdb 进行内核调试(请参阅此设置指南),有人问我为什么不使用 kvm?
所以我问:内核调试/USB驱动开发的kvm vs. vmware
各自的优缺点是什么?
我目前正在设置 vmware Server 2.0 以使用 gdb 进行内核调试(请参阅此设置指南),有人问我为什么不使用 kvm?
所以我问:内核调试/USB驱动开发的kvm vs. vmware
各自的优缺点是什么?
驱动开发?您是否正在为特定硬件开发驱动程序?如果是这样,那么您可能无法使用虚拟化,因为虚拟化实例将无法访问新硬件。
为此,您将需要两台机器,一台在另一台上运行远程调试器。
*编辑:*显然您正在为 USB 设备开发驱动程序?这是一个特别是虚拟机实际上可以提供帮助的领域。如今,大多数虚拟机都能够将特定的 USB 设备委托给来宾操作系统。
也就是说,与远程调试器选项相比,这种情况并没有真正提供任何好处,因为您仍然需要一种方法来检查正在运行或崩溃的操作系统的状态,而虚拟机在这方面提供的帮助很少。您可能能够重播崩溃前保存的状态。
您可能能够使用 UML 获得一些牵引力,这将允许您像在常规用户进程上一样进行本地调试,这样麻烦会少一些。
我最近开始构建 GNU Mach/HURD,发现 QEmu/KVM 的组合工作得非常好......原因如下:
底线是,对于内核工作,我只希望启动最少的功能并查看结果。VMWare 更多的是用于可用的虚拟化而不是肮脏的。
但是,无法与在具有真实硬件的真实机器上启动相比。VM 环境有时看起来像是一个安全毯……因为即使是我的烤面包机也会知道 Realtek RTL8139C 是什么。
如果它是一个“真正的硬件”设备,当然,vmware 不会模拟它,所以你将无法调试它下的驱动程序(任何其他虚拟化软件也不能,除非你扩展一个来这样做)。
设备驱动程序调试可以在一定程度上使用具有普通内核的真实硬件机器来完成——尽管显然有些事情你不能做——比如设置断点。
仍然可以将调试器附加到内核并检查内容。此外,传统的 printf() 调试是完全可行的(printk,anyone),并且内核中的各种特性使调试更容易。可以使用各种调试选项构建内核,以尝试检测指针问题、内存泄漏等。
默认情况下,当内核遇到 OOPS 或 BUG 情况时,它甚至会在日志上提供漂亮的堆栈跟踪(显然,如果系统挂起或崩溃,这不一定会写入任何地方)。当然,中断内发生的指针超出范围的情况是灾难的根源,但是您仍然可以在恐慌之前立即在屏幕上获得堆栈跟踪:)