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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130812181956.GB19405@gmail.com>
Date:	Mon, 12 Aug 2013 20:19:56 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	acme@...radead.org, Andi Kleen <ak@...ux.intel.com>,
	Namhyung Kim <namhyung.kim@....com>, peterz@...radead.org
Subject: Re: [PATCH] RFC: perf, tools: Move gtk browser into separate perfgtk
 executable

* Christoph Hellwig <hch@...radead.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/