On 11/06/2011 09:17 PM, Pekka Enberg wrote:
> No. I want to try new tool/old kernel and old tool/new kernel (kernel can > be either guest or host, depending on the nature of the bug), and then > bisect just one. (*) And that's the exceptional case, and only KVM tool > developers really should have the need to do that. Exactly - having the source code in Linux kernel tree covers the "exceptional case" where we're unsure which part of the equation broke things (which are btw the nasties issues we've had so far).
No, having the source code in Linux kernel tree is perfectly useless for the exceptional case, and forces you to go through extra hoops to build only one component. Small hoops such as adding "-- tools/kvm" to "git bisect start" perhaps, but still hoops that aren't traded for a practical advantage. You keep saying "oh things have been so much better" because "it's so close to the kernel" and "it worked so great for perf", but you haven't brought any practical example that we can stare at in admiration.
(BTW, I'm also convinced like Ted that not having a defined perf ABI might have made sense in the beginning, but it has now devolved into bad software engineering practice).
I have no idea why you're trying to convince me that it doesn't matter.
I'm not trying to convince you that it doesn't matter, I'm trying to convince you that it doesn't *make sense*.
It's a hypervisor that implements virtio drivers, serial emulation, and mini-BIOS.
... all of which have a spec against which you should be working. Save perhaps for the mini-BIOS, if you develop against the kernel source rather than the spec you're doing it *wrong*. Very wrong. But you've been told this many times already.
Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
