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 16:06:40 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Pekka Enberg <penberg@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Randy Dunlap <rdunlap@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	David Rientjes <rientjes@...gle.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Sasha Levin <levinsasha928@...il.com>,
	"H. Peter Anvin" <hpa@...or.com>, Michal Marek <mmarek@...e.cz>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)

On Sun, Feb 10, 2013 at 06:57:41AM +1100, Linus Torvalds wrote:
> THAT is my main contention. I told you why I think it's actually
> actively untrue. You claim it helps, but what is it about kvmtool that
> makes it so magically helpful to be inside the kernel repository? What
> is it about this that makes it so critical that you get the kernel and
> kvmtool with a single pull, and they have to be in sync? When you then
> at the same time claim that you make very sure that they don't have to
> be in sync at all. See your earlier emails about how you claim to have
> worked very hard to make sure they work across different versions.

I completely agree with Linus here; in fact, the main reason why it's
important to keep userspace tools outside of the kernel is that it
keeps us careful about interface design.

For example, I consider it a *feature* that when we extend the file
system data structures for ext4, they have to be made in the two
places; once in the kernel, and once in e2fsprogs's version of
ext2_fs.h.  Yes, it might be more convenient if we pushed all of
e2fsprogs into the kernel, so I wouldn't have to edit ext2_fs.h in two
places, but when I make changes to ext2_fs.h, I want to be really
careful, lest I not break backwards compatibility, and to think very
carefully about forward compatibility issues.

If there are constantly huge numbers of interface changes in the
kernel/userspace interface, then it increases the chances that
mistakes will be made.  It's better that those mistakes be caught
early, and if changes need to be made in two places, it increases the
chances that these mistakes will be noticed sooner rather than later.

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