Re: [GIT PULL] Performance Counters for Linux

[Ingo Molnar <mingo@elte.hu>]

* Marcel Holtmann <marcel@holtmann.org> wrote:

> Hi Ingo,
> 
> > > What the "keep it in the kernel sources" approach hopefully allows is
> > > 
> > >  - taking advantage of new features in a timely manner.
> > > 
> > >    NOT with some ABI breakage, but simply things like supporting a 
> > >    new CPU architecture or new counters. The thing that oprofile 
> > >    failed at so badly in my experience.
> > >
> > >  - Make it easier for developers, and _avoiding_ the horrible 
> > >    situation where you have two different groups that don't talk 
> > >    well to each other because one is a group of user-space 
> > >    weenies, and the other is a group of manly kernel people, and 
> > >    there is no common ground.
> > 
> > Yes, very much agreed.
> > 
> > Btw., here are a couple of other arguments why i find it useful to 
> > have the tools/perf/ in the kernel repo:
> > 
> > 1) Super-fast and synchronized release cycles
> > 
> > The kernel is one of the fastest moving packages in Linux - most 
> > user-space packages have (much!) longer release cycles than 3 
> > months.
> 
> that might be true for some projects, but for others this is 
> wrong. You are just making an assumption out of thin air.
> 
> > A tight release schedule forces a certain amount of release 
> > discipline on tooling as well - so i'm glad that the two will be 
> > coupled. It's so easy for a promising tool to degrade into 
> > tinkerware with odd release cycles with time - if it's part of 
> > the kernel then at least the release cycles wont be odd but at 
> > precise 3 months.
> 
> And you can't do that within a perf.git tree on kernel.org 
> because?

We actually tried the tools as separate code, and for the first 
three months of the project we only got three contributions - while 
the kernel code was essentially finished. (Pekka reported a similar 
experience in this thread, with another tool that has close kernel 
ties.)

Once we moved it into the same repo as the kernel code (three months 
ago), the patches started flowing in - at an amazing rate. We now 
have a dozen contributors, most of them kernel developers, and we 
have over a hundred good changes to the tools - in just another 3 
months.

The key difference was the location of the tools. It is very 
convenient and productive to have a shared repository for a project 
that frequently involves both kernel and tool changes.

So my point is: this model clearly works in practice and all the 
current tools/perf/ contributors like this kind of coding 
environment.

Most of your arguments seem to center around the notion that it 
could all be done in a separate repo too and that such a repo could 
be run as well as the Linux kernel. If you think you could do it 
even better in a separate repo you are certainly free to try it.

	Ingo