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

[Ingo Molnar]

* Avi Kivity <avi@xxxxxxxxxx> wrote:

> On 03/21/2010 09:06 PM, Ingo Molnar wrote:
> >* Avi Kivity<avi@xxxxxxxxxx>  wrote:
> >
> >>>>[...] Second, from my point of view all contributors are volunteers
> >>>>(perhaps their employer volunteered them, but there's no difference from
> >>>>my perspective). Asking them to repaint my apartment as a condition to
> >>>>get a patch applied is abuse.  If a patch is good, it gets applied.
> >>>This is one of the weirdest arguments i've seen in this thread. Almost all
> >>>the time do we make contributions conditional on the general shape of the
> >>>project. Developers dont get to do just the fun stuff.
> >>So, do you think a reply to a patch along the lines of
> >>
> >>   NAK.  Improving scalability is pointless while we don't have a decent GUI.
> >>I'll review you RCU patches
> >>   _after_ you've contributed a usable GUI.
> >>
> >>?
> >What does this have to do with RCU?
> 
> The example was rcuifying kvm which took place a bit ago.  Sorry, it wasn't 
> clear.
> 
> > I'm talking about KVM, which is a Linux kernel feature that is useless 
> > without a proper, KVM-specific app making use of it.
> >
> > RCU is a general kernel performance feature that works across the board. 
> > It helps KVM indirectly, and it helps many other kernel subsystems as 
> > well. It needs no user-space tool to be useful.
> 
> Correct.  So should I tell someone that has sent a patch that rcu-ified kvm 
> in order to scale it, that I won't accept the patch unless they do some 
> usability userspace work?  say, implementing an eject button. That's what I 
> understood you to mean.

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. '

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. '

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

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.

Which, btw., is an unconditonally good thing ...

But even an RCU speedup can be fairly linked/ordered to more pressing needs of 
a project.

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

Thanks,

	Ingo
--
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/