linux-kernel - Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels

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, 07 Nov 2011 13:08:50 +0100
From:	Gerd Hoffmann <kraxel@...hat.com>
To:	Pekka Enberg <penberg@...helsinki.fi>
CC:	Pekka Enberg <penberg@...nel.org>, Alexander Graf <agraf@...e.de>,
	Avi Kivity <avi@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	"linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>,
	"kvm@...r.kernel.org list" <kvm@...r.kernel.org>,
	qemu-devel Developers <qemu-devel@...gnu.org>,
	Américo Wang 
	<xiyou.wangcong@...il.com>, Blue Swirl <blauwirbel@...il.com>
Subject: Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels

On 11/07/11 12:34, Pekka Enberg wrote:
> On Mon, 7 Nov 2011, Gerd Hoffmann wrote:
>>> It's not just about code, it's as much about culture and development
>>> process.
>>
>> Indeed.  The BSDs have both kernel and the base system in a single
>> repository.  There are probably good reasons for (and against) it.
>>
>> In Linux we don't have that culture.  No tool (except perf) lives in the
>> kernel repo.  I fail to see why kvm-tool is that much different from
>> udev, util-linux, iproute, filesystem tools, that it should be included.
> 
> You seem to think perf is an exception - I think it's going to be the
> future norm for userspace components that are very close to the kernel.

perf *is* an exception today.

It might make sense to change that.  But IMHO it only makes sense if
there is a really broad agreement on it and other core stuff moves into
the kernel too.  Then you'll be able to get advantages out of it.  For
example standardizing the process to create an initramfs (using the
userspace tools shipped with the kernel) instead of having each distro
creating its own way.

I somehow doubt we'll see such an broad agreement though.  Most people
seem to be happy with the current model.  There is a reason why the
klibc + early-userspace-in-kernel-tree project died in the end ...

cheers,
  Gerd
--
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/