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]

Message-ID: <20111107122902.GA24685@thunk.org>
Date:	Mon, 7 Nov 2011 07:29:02 -0500
From:	Ted Ts'o <tytso@....edu>
To:	Gerd Hoffmann <kraxel@...hat.com>
Cc:	Pekka Enberg <penberg@...helsinki.fi>,
	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 Mon, Nov 07, 2011 at 01:08:50PM +0100, Gerd Hoffmann wrote:
> 
> 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 wish distributions had standardized on a single initramfs, sure.
But that doesn't mean that the only way to do this is to merge
userspace code into the kernel source tree.  Everybody uses fsck,
originally from the e2fsprogs source tree, and now from util-linux-ng,
and that isn't merged into the kernel sources.

And I think would be actively *harmful* to merge util-linux-ng into
the kernel sources.  For a variety of reasons, you may want to upgrade
util-linux-ng, and not the kernel, or the kernel, and not
util-linux-ng.  If you package the two sources together, it becomes
unclear what versions of the kernel will work with which versions of
util-linux-ng, and vice versa.  Suppose you need to fix a security bug
in some program that lives in util-linux-ng.  If it was bundled inside
the kernel, a distribution would now have to release a kernel source
package.  Does that mean that it will have to ship the a new set of
kernel binaries?  Or does the distribution have to ship multiple
binary packages that derive from the differently versioned source
packages?

And the same problems will exist with kvm-tool.  What if you need to
release a new version of kvm-tool?  Does that mean that you have to
release a new set of kernel binaries?  It's a mess, and there's a
reason why we don't have glibc, e2fsprogs, xfsprogs, util-linux-ng,
etc., all packaged into the kernel sources.

Because it's a stupid, idiotic thing to do.

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