Re: [RFC] Unify KVM kernel-space and user-space code into a singleproject

[Avi Kivity]

On 03/21/2010 10:55 PM, Ingo Molnar wrote:
> Of course you could say the following:
>
>    ' Thanks, I'll mark this for v2.6.36 integration. Note that we are not
>      able to add this to the v2.6.35 kernel queue anymore as the ongoing
>      usability work already takes up all of the project's maintainer and
>      testing bandwidth. If you want the feature to be merged sooner than that
>      then please help us cut down on the TODO and BUGS list that can be found
>      at XYZ. There's quite a few low hanging fruits there. '
>    

That would be shooting at my own foot as well as the contributor's since 
I badly want that RCU stuff, and while a GUI would be nice, that itch 
isn't on my back.

You're asking a developer and a maintainer to put off the work they're 
interested in, in order to work on something someone else is interested 
in, but not contributing the work.

> Although this RCU example is 'worst' possible example, as it's a pure speedup
> change with no functionality effect.
>
> Consider the _other_ examples that are a lot more clear:
>
>     ' If you expose paravirt spilocks via KVM please also make sure the KVM
>       tooling can make use of it, has an option for it to configure it, and
>       that it has sufficient efficiency statistics displayed in the tool for
>       admins to monitor.'
>
>     ' If you create this new paravirt driver then please also make sure it can
>       be configured in the tooling. '
>
>     ' Please also add a testcase for this bug to tools/kvm/testcases/ so we dont
>       repeat this same mistake in the future. '
>    

All three happen quite commonly in qemu/kvm development.  Of course 
someone who develops a feature also develops a patch that exposes it in 
qemu.  There are several test cases in qemu-kvm.git/kvm/user/test.

> I'd say most of the high-level feature work in KVM has tooling impact.
>    

Usually, pretty low.  Plumbing down a feature is usually trivial.  There 
are exceptions, of course - smp is only supported in qemu-kvm.git, not 
in upstream qemu.git, for example.  In any case of course the work is 
done in both qemu and kvm - do you think people develop features to see 
them bitrot?

> And note the important arguement that the 'eject button' thing would not occur
> naturally in a project that is well designed and has a good quality balance.
> It would only occur in the transitionary period if a big lump of lower-quality
> code is unified with higher-quality code. Then indeed a lot of pressure gets
> created on the people working on the high-quality portion to go over and fix
> the low-quality portion.
>    

It's a matter of priorities.

> Which, btw., is an unconditonally good thing ...
>
> But even an RCU speedup can be fairly linked/ordered to more pressing needs of
> a project.
>    

Pressing to whom?

> Really, the unification of two tightly related pieces of code has numerous
> clear advantages. Please give it some thought before rejecting it.
>    

I'm not blind to the advantages.  Dropping tcg would be the biggest of 
them by far (much more than moving the repository, IMO).  But there are 
disadvantages as well.

Around two years ago I seriously considered forking qemu, at this time I 
do not think it is a good idea.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/