linux-kernel - Re: [GIT PULL] Native Linux KVM tool for 3.1

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]

Message-ID: <20110725102802.GJ28787@elte.hu>
Date:	Mon, 25 Jul 2011 12:28:02 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Alexander Graf <agraf@...e.de>
Cc:	Pekka Enberg <penberg@...nel.org>, Jan Kiszka <jan.kiszka@....de>,
	torvalds@...ux-foundation.org, avi@...hat.com,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org, gorcunov@...il.com, levinsasha928@...il.com,
	asias.hejun@...il.com, prasadjoshi124@...il.com
Subject: Re: [GIT PULL] Native Linux KVM tool for 3.1

* Alexander Graf <agraf@...e.de> wrote:

> On 25.07.2011, at 11:41, Ingo Molnar wrote:
> 
> >>> Virtualization is very tightly bound to the kernel, like it or 
> >>> not. So is profiling, power management and a few other things.
> > 
> > It's a very simple point and observation: tools which integrate 
> > to the kernel so that they wouldnt even run on another kernel 
> > obviously are very natural to develop in tools/.
> 
> Ah, very good. So all we need to do to prove the point that 
> kvm-tool doesn't belong in tools/ is port KVM to another OS and 
> make kvm-tool compile there too? Shouldn't be too hard. People 
> already have working ports of (old) KVM versions on FreeBSD and 
> Windows.

Firstly, tools/kvm/ itself only works on Linux and it's developed in 
the kernel repo and we see many benefits of that model and are happy 
with it.

Secondly, even your argument is rather inconsistent: by your argument 
what keeps KVM itself within the Linux kernel, if it's so portable to 
FreeBSD and Windows? By your argument all the virtio drivers should 
be moved out of the Linux kernel tree, to support both the FreeBSD, 
Windows and Linux KVM implementations. By your argument the arch/x86/ 
KVM disassembler should move out of the kernel tree, etc. etc.

You cannot have it both ways really.

So yes, i disagree with you rigid views about this, in reality what 
matters is the quality of the end result and the preferences of the 
developers. Just like i cannot (and should not) force you to develop 
in tools/qemu/, should you not try to force me to not develop in 
tools/kvm/.

Thanks,

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