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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
