On Fri, 2011-11-04 at 17:26 +0100, Jan Kiszka wrote: > On 2011-11-04 16:16, Sasha Levin wrote: > > 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. > > This can happen if the kernel API went totally wrong on the first run. > It happens, but not frequently. Or do you see many examples for this in > KVM's history? A recent example is the NMI emulation fix which reached v6 for both trees. And from what I gather it's supposed to be a smaller scale change than the virtio one I've mentioned before. There are more similar examples. > > I don't remember finding this particularly problematic for any of my own > patch sets. If the API is controversial, you usually try to get that > conceptually resolved instead of updating all bits over and over again. > Once the API is accepted, changes to the implementations become > independent anyway. > > > > > 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 :) > > Synching headers has become trivial these days (reloading updated KVM > modules may take more steps ;) ). Yup, it's a simple copy - I didn't say it was hard, I said it's ugly. > > > > 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. > > I can't imagine that the ability to do a single 'make' for a change that > remains split nevertheless justifies merging more user land into the > kernel. You can always set up a meta project for this. Thats not the only reason for the merge ofcourse, it's just one which you asked about. You can do a meta project, you can't send patches out like that though - which makes that meaningless. -- 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
