linux-kernel - Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 9 Feb 2013 11:45:50 +1100
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Pekka Enberg <penberg@...nel.org>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	David Rientjes <rientjes@...gle.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Sasha Levin <levinsasha928@...il.com>,
	Randy Dunlap <rdunlap@...radead.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Michal Marek <mmarek@...e.cz>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)

On Sat, Feb 9, 2013 at 10:57 AM, Pekka Enberg <penberg@...nel.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/