Re: [PATCH] RFC: perf, tools: Move gtk browser into separate perfgtk executable

[Ingo Molnar <mingo@kernel.org>]

* Christoph Hellwig <hch@infradead.org> wrote:

> On Mon, Aug 05, 2013 at 11:08:57AM +0200, Ingo Molnar wrote:
> > You never replied to the original counter-arguments, such as this one from 
> > Linus:
> > 
> >   http://article.gmane.org/gmane.linux.kernel/849965
> 
> The only thing Linus sais is that it's trivial to generate a subpackage, 
> and that opofile is a desaster.  Both of them are 100% correct but at 
> the same time entirely miss the point.
> 
> Yes, oprofile was and is a desaster, but that has aboslutely nothing to 
> do with where the code lives.
> 
> And yes, it's easy to generate a subpackage, but you still need all the 
> source tree first. [...]

And the kernel source tree is not particularly hard to get so what's your 
point? ...

> [...]  There's a reason why things like X.org got split up (too fine 
> grained in my opinion, but that's another story).

X.org got split up for all the wrong reasons, it's still a unified project 
by and large, and the different components only work reliably when going 
in lockstep so it's not like there's a true ABI between them.

So I really hope you don't advocate for that.

perf is the exact opposite: no split-up the development culture because 
they are closely related, yet a relatively disciplined ABI between the 
components. In fact the ABI is higher quality exactly because development 
is more integrated and allows for ABI problems to be resolved before they 
leak out. It also allows for faster iteration of development, without 
nonsensical ABI steps pulluting the way.

> As said I very much disagree with having the userspace perf tree in the 
> kernel still, but I've also given up on the fight as I have more 
> important things to do.
> 
> And as said before it has nothing to do with the issue discussed here 
> right now.

My point is that it's a very similar meta argument: splitting up perf 
usage space would be nonsensical and harmful in a similar fashion as it 
would be harmful to split up the perf development space.

Put differently: there's strong benefits to having a unified perf 
development environment and there's equally strong benefits on the user 
side to have a unified perf usage environment that a single command 
represents.

The benefits are not absolute and not unconditional, and any costs of 
integration should be minimized to the best of our ability, but I hope you 
get the drift of my argument ...

Thanks,

	Ingo