lkml.org 
[lkml]   [2013]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)

* Theodore Ts'o <tytso@mit.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


\
 
 \ /
  Last update: 2013-02-11 14:21    [W:0.127 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site