lkml.org 
[lkml]   [2013]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
On Sat, Feb 9, 2013 at 10:57 AM, Pekka Enberg <penberg@kernel.org> wrote:
>
> And yes, you are absolutely correct that living in the kernel tree is
> suboptimal for the casual user. However, it's a trade-off to make
> tools/kvm *development* easier especially when you need to touch both
> kernel and userspace code.

Quite frankly, that's just optimizing for the wrong case.

The merged case seems to make sense for you and Ingo, and nobody else.

And then you wonder why nobody else wants to merge it.

I've told you my reasons, you didn't give me *any* actual reasons for
me to merge the code. NONE of your statements made any sense at all,
since everything you talk about could have been done with a separate
project.

The only thing the lock-step does is to generate the kind of
dependency that I ABSOLUTELY DETEST, where one version of kvmtools
goes along with one version of the kernel. That's a huge disadvantage
(and we've actually seen signs of that in the perf tool too, where old
versions of the tools have been broken, because the people working on
them have been way too much in lock-step with the kernel it is used
on).

And if it's not the case that they have to be used in lockstep, then
clearly kvmtool developers could just as easily just have a separate
git repository.

So you can't have it both ways. What's so wrong with just making it a
separate project?

Linus


\
 
 \ /
  Last update: 2013-02-09 02:21    [W:0.277 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site