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]

Date:	Mon, 25 Jul 2011 10:31:51 +0200
From:	Alexander Graf <agraf@...e.de>
To:	Pekka Enberg <penberg@...nel.org>
Cc:	Ingo Molnar <mingo@...e.hu>, 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


On 25.07.2011, at 10:23, Pekka Enberg wrote:

> Hi Alexander,
> 
> On Mon, Jul 25, 2011 at 11:14 AM, Alexander Graf <agraf@...e.de> wrote:
>>> Same here - in fact i first asked Qemu to be put into tools/qemu/ so
>>> that it all becomes more hackable and more usable - that suggestion
>>> was rebuked very strongly.
>> 
>> So instead of thinking a bit and trying to realize that there might be a reason people don't want all their user space in the kernel tree you go ahead and start your own crusade of creating a new user space. Great. That's how I always hoped Linux would be :(.
> 
> Damn you Ingo Molnar, I knew you'd somehow get all the credit for our
> hard work! ;-)

Well, IIUC he's the one initiating the whole thing, no?

> More seriously, though, I fail to see what's bothering you Alexander.
> I and Ingo already mentioned we wouldn't be hacking on Qemu even if
> there wasn't no tools/kvm. It's not as if we're putting *your* user
> space code into the kernel tree - we wrote our own! What's wrong with
> that?

Nothing. I like competition. But why push it into the kernel? It's not a kernel, it's not a library the kernels needs for internal stuff. So why would it have to be in there?

In Ingo's reasoning, the next step would be to rewrite glibc and put it into the kernel tree, because we end up adding syscalls so adding them to the in-kernel libc with the same commit would be a lot easier and cleaner.


Alex

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