On Fri, 2011-11-04 at 15:42 +0100, Jan Kiszka wrote: > On 2011-11-04 14:32, Pekka Enberg wrote: > > I know you don't see the benefits of integrated code base but I as a > > developer do. > > IIRC, this discussion still lacks striking, concrete examples from the > KVM tool vs. QEMU development processes. I'll give a current example: Michael and Rusty are currently considering a change in the virtio spec (allowing MMIO config BARs - but thats irrelevant). I'll quote what Anthony said about how he sees the big picture of how this change is going to be implemented - something which we all agree with: On Thu, 2011-11-03 at 09:37 -0500, Anthony Liguori wrote: > Well, what's needed before the spec is changed is an interesting question, but I > think the main thing is, don't commit any virtio ABI changes to vhost, QEMU, > NKT, or the kernel until the spec for the change has been committed. > > It would be nice to have a working implementation before committing a spec > change. Even nicer would be to have Acked-by's a maintainer in each area affected. Which is pretty smart. Get a working implementation before we commit to a spec. Now, how would the development process look when the trees aren't integrated? You'd try to get the kernel side stabilized, then you'd do your usermode changes, go back to the kernel patches to fix bugs and things people missed, which would require in turn new patches to the usermode part, and so until you get 5-6 versions (best case) of this change in *each* tree. Add some technical difficulties which just make it uglier, such as having to copy over new kernel headers into the usermode tool for each new version you want to send (linux-headers/ dir in QEMU) and you get a process which is not that pretty anymore :) How would it look for an integrated project? You'd be working on the same codebase, one series of patches would take care of both the kernel changes and the userspace changes, this would speed up iterations and make testing quite easier. -- Sasha. -- 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
