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

[Steven Rostedt <rostedt@goodmis.org>]

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. 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. Only one other person has contributed to me, and that
was just some minor changes. I still find it awkward to work on ktest
inside the kernel. I have a separate tree just for ktest, and that means
I have all the kernel files sitting there doing nothing just to be able
to work on 2 files.

Then there's the issue of waiting for Linus to pull from me. I posted my
patch set on Oct 28th, and it didn't make it into the merge window. I
don't know if Linus had an issue with it, or it just got lost in the
noise, as Linus has a lot of other things to worry about. This brings up
another question. Does Linus scale? Having more tools in the kernel
repo requires Linus to pull from more sources. Or are we just going to
have to have a "tools" maintainer. This will give a lot of control to
that person who is the gate keeper of the tools directory.

Now I've kept trace-cmd and kernelshark outside the kernel tree. I've
received lots of patches from other developers for it and some nice new
features. It requires me to think hard to keep a nice ABI, and it has
been working nicely. The event parsing is working well and there's even
a library. But I haven't pushed it too hard because I want this to apply
to perf as well. But due to disagreements of where in the kernel tree it
belongs, it has been over a year with no progress. Now we waste 4 bytes
for every event recording a non existent big kernel lock counter. For
recording a million events (which is actually low) that's 4Megs of
wasted kernel memory. New tracepoints are going into the kernel all the
time, and without a library, we are increasing the chance that more
tools will break on changes, and tracepoints will lock down kernel
inovation soon if something is not done.

Anyway, I'm having surgery tomorrow and have other things to work on.

-- Steve