linux-kernel - Re: [PATCH 2/7] perf: New helper function for pmu name

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]

Date:	Wed, 6 Oct 2010 17:37:10 +0200
From:	Robert Richter <robert.richter@....com>
To:	Paul Mundt <lethal@...ux-sh.org>
CC:	Peter Zijlstra <peterz@...radead.org>,
	Matt Fleming <matt@...sole-pimps.org>,
	Will Deacon <will.deacon@....com>,
	Russell King <linux@....linux.org.uk>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-sh@...r.kernel.org" <linux-sh@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Deng-Cheng Zhu <dengcheng.zhu@...il.com>,
	Grant Likely <grant.likely@...retlab.ca>
Subject: Re: [PATCH 2/7] perf: New helper function for pmu name

On 06.10.10 10:13:47, Paul Mundt wrote:
> On Wed, Oct 06, 2010 at 10:30:41PM +0900, Paul Mundt wrote:
> > On Wed, Oct 06, 2010 at 03:18:25PM +0200, Robert Richter wrote:
> > > I am not against adding the pmu name to the perf API. But the oprofile
> > > cpu_type strings are oprofile centric esp. for the userland. So these
> > > strings will remain part of oprofile. Also I don't think we want to
> > > polute the perf pmu names with it.
> > > 
> > And those architectures that have opted to use different strings for perf
> > events are free to mangle them however they want for the oprofile case.
> > It doesn't change the fact that strings are still being managed by all of
> > the architectures. The perf PMU names aren't presently locked in to an
> > ABI, whereas the oprofile strings are, so it seems fairly straightforward
> > to develop standard mangling rules for preventing an oprofile-facing
> > string, or to simply reuse the strings verbatim.
> > 
> So to add a bit of context here, I was just looking at the oprofile
> tools. The naming format here is one of:
> 
> 	<arch>/<pmu>

Do you really want the oprofile name scheme move to perf?

> 
> if there were a generic perf to oprofile pmu name mangler that did this

Or, do you mean here to derive an oprofile name from the pmu string in
a generic way? I was suggesting this for SH when commenting on version
3 of this patch set. We dropped this idea to keep changes simple for
this initial patch set, because it was much easier to implement it
with strcmp() and the pmu strings are not expected to be changed for
sh in the near future.

So, can't we use op_name_from_perf_name() from [PATCH -v3 6/6] for SH
here and implement a perf_pmu_name() function for sh that is part of
perf's generic interface? 

Later we can add a generic function for sh ...

> it would cover almost all of the ARM cases already, the SH strings I'm
> happy to convert to work this way, and a good chunk of the PowerPC PMUs
> would work fine, too. PowerPC already has an oprofile CPU string in its
> CPU spec, so this would be even more trivial to wire up there if such a
> generic interface were to exist.
> 
> This would just leave x86 as the odd one out, but I suppose if x86 were
> to move to the oprofile perf wrapper in the future then a bit of id to
> name mangling as an override wouldn't be too much work.

... and also other architectures on top of these patches.

Thanks,

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center

--
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/