linux-kernel - Re: [PATCH 0/26] oprofile: Performance counter multiplexing

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 4 Aug 2009 19:05:45 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Robert Richter <robert.richter@....com>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Paul Mackerras <paulus@...ba.org>,
	LKML <linux-kernel@...r.kernel.org>,
	oprofile-list <oprofile-list@...ts.sourceforge.net>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Mike Galbraith <efault@....de>,
	Arjan van de Ven <arjan@...radead.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 0/26] oprofile: Performance counter multiplexing

* Robert Richter <robert.richter@....com> wrote:

> On 03.08.09 13:22:20, Ingo Molnar wrote:
> > 
> > Now i'm also co-maintaining perfcounters and because it's a full 
> > oprofile replacement (which aspect Robert seems to disagree with 
> > ;-)
> 
> I can't imagine a full oprofile replacement. This would require a 
> rewrite of all userland tools and also the complete port of all 
> architectures (which has to be done for each architecture 
> individually). And first of all, I don't think it is necessary to 
> do this, why not keep different interfaces for different purposes?

Perfcounters and tools/perf/ intends to be everything that oprofile 
is - just implemented in a better way. What 'different purposes' do 
you mean?

Lets admit it: the oprofile kernel-side code has been mis-designed 
from the get go and it is unfixable in its current form. The 
mis-design is hardcoded in the oprofile ABIs and into portions of 
the oprofile tooling. If you wanted to fix that you'd have to 
rewrite the whole thing from scratch.

And the thing is, we already did that: the 'fix' for oprofile is 
perfcounters and the perf tool ;-) This is why we developed and 
merged perfcounters upstream and did not extend oprofile to begin 
with.

All in one, Oprofile is largely obsolete and i dont see that 
realization from your patches. I see a lot of ongoing churn coming 
up on the oprofile kernel side and i'm not sure i want to assist 
that, because i think it's stupid and i dont like doing or helping 
stupid things.

So please either convince me that it's not obsolete, or lets state 
it as a fundamental disagreement that you dont think that oprofile 
is obsolete and that you still want to develop it.

	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/