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

[Sasha Levin <levinsasha928@gmail.com>]

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.