Re: [RFC/GIT PULL] Linux KVM tool for v3.2

[Sasha Levin <levinsasha928@gmail.com>]

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.