lkml.org 
[lkml]   [2013]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] RFC: perf, tools: Move gtk browser into separate perfgtk executable

* 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


\
 
 \ /
  Last update: 2013-08-12 20:41    [W:0.055 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site