Re: [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/

Ingo Molnar
2011-11-09T09:23:08Z

* Steven Rostedt <rostedt@goodmis.org> wrote:

> On Tue, Nov 08, 2011 at 10:32:25AM +0100, Ingo Molnar wrote:
> >
> > None of the perf developers with whom i'm working complained
> > about the shared repo so far - publicly or privately. By all
> > means they are enjoying it and if you look at the stats and
> > results you'll agree that they are highly productive working in
> > that environment.
>
> Just because you brought it up.
>
> I personally find it awkward to work in the linux tools directory.
> Maybe this is the reason that I haven't been such a big contributor
> of perf. [...]

Well, this is an argument with a long history we've had from the
moment we started perf - i think the main underlying reason for that
is that you still see perf as competition to ftrace instead of seeing
perf the child of ftrace, the next version of ftrace, the next
iterative step of evolution :-/

Unfortunately there's not much that i can do about that beyond
telling you that you are IMHO wrong - you as the main ftrace
developer thinking that it's competition is a self-fulfilling
expectation.

Eventually someone will do the right thing and implement 'perf trace'
(there's still the tip:tmp.perf/trace2 prototype branch) and users
will flock to that workflow because it's so much more intuitive in
practice. From what i've seen from the short prototype experiments
i've conducted it's a no-brainer superior workflow and design.

> [...] I only pushed ktest into the kernel tools directory because
> people convinced me to do so. Having it there didn't seem to bring
> in many other developers. [...]

It was somewhat similar with perf - contributors only arrived after
it went upstream, and even then with a delay of a few releases.

Also, and it pains me to have to mention it, but putting a .pl script
into the kernel repo is not necessarily a reciepe for attracting a
lot of developers. We went to great lengths to kill the .cc perf
report file in perf, to keep the programming environment familiar to
kernel developers and other low level utility folks.

Also, obviously a tool has to be important, interesting and has to
offer a distinct edge over other tools to attract contributors. Maybe
tools/testing/ktest/ does not sound that interesting? Naming also
matters: i sure would have moved it to tools/ktest/, its name already
suggests that it's about testing, why repeat that twice? Sounds
weird.

In that sense tools/kvm/ is better than perf: it has already
attracted a core group of good, productive contributors despite still
being an out of tree fork.

The point here was that Pekka & co not just clearly enjoys working on
tools/kvm/ and has no trouble attracting contributors, but also
*relies* on it being in the kernel tree.

Thanks,

Ingo