Message-ID: <20130211123827.GB5802@gmail.com>
Date:	Mon, 11 Feb 2013 13:38:27 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Theodore Ts'o <tytso@....edu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	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>
Subject: Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)


* Theodore Ts'o <tytso@....edu> wrote:

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

We have first hand experience there: tools/perf/.

None of the predicted extreme badness happened. Yes, sometimes 
we broke compatibility as ABI changes/enhancements do - but 
treated them as regressions and fixed them. I also think that 
considering the rate of changes our breakage ratio is very good.

So no badness happened, and in fact a lot of goodness happened: 
which goodness never happened while Linux profiling was a 
separate project isolated as a user-space utility!

Anyone opposing integration I think *HAS* to explain the 
mechanics behind this very example in plain sight.

Why the heck has pretty much every other out of tree profiling 
project died, while the in-tree one is thriving?

Yes, the key is that Arnaldo is good, and so are the other perf 
contributors - and they are good because they feel at home and 
they are productive. Being in the kernel repo is actually 90% 
responsible for that environment!

> For example, I consider it a *feature* that when we extend the 
> file system data structures for ext4, [...]

I consider filesystems the most extreme example. It's so extreme 
that it's almost a separate class for itself.

Filesystems have the most extreme data persistency constraints 
possible: they define the ABI and anything that gets written out 
through them to persistent storage stays there forever and has 
to work, years down the line. So one must be absolutely, 110% 
careful - to the level of inventing new validation technologies 
just to be more careful.

*NONE* of that applies to tools/perf/ or tools/kvm/: neither 
really writes any data structure defined by itself that will be 
persistent forever. perf.data comes closest, but when was it the 
last time you used a year old perf.data? I'd say never. It 
either gets used within a few days or does not get used at all.

( Yet we even keep perf.data compatibility because being careful 
  about data is generally good technology - it's just not 
  *critical*. )

Same goes for tools/kvm/: it has very short data persistency 
latency as well. Such are in fact most other kernel related 
utilities.

So your 'filesystem utilities' example is totally inapplicable 
to tools/perf/ and tools/kvm/. Shaping all utilities based on 
that extreme example is a sad mistake.

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/

Powered by blists - more mailing lists