linux-kernel - Re: [PATCH/RFC v1 0/2] Human readable performance event description in sysfs

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: <20100120150303.GG4089@wear.picochip.com>
Date:	Wed, 20 Jan 2010 15:03:03 +0000
From:	Jamie Iles <jamie.iles@...ochip.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Jamie Iles <jamie.iles@...ochip.com>, jpihet@...sta.com,
	p.osciak@...sung.com, will.deacon@....com,
	Michał Nazarewicz <m.nazarewicz@...sung.com>,
	linux-kernel@...r.kernel.org, kyungmin.park@...sung.com,
	mingo@...e.hu, m.szyprowski@...sung.com,
	linux-arm-kernel@...ts.infradead.org,
	Tomasz Fujak <t.fujak@...sung.com>
Subject: Re: [PATCH/RFC v1 0/2] Human readable performance event
	description in sysfs

On Wed, Jan 20, 2010 at 02:41:40PM +0000, Russell King - ARM Linux wrote:
> Given that history has shown that identification schemes on ARM change
> in extremely annoying ways, I don't think decoding these registers to
> some kind of textual representation for /proc/cpuinfo is the right
> approach.  It might instead make more sense to just export the entire
> set of CPU ID registers to userspace, and let userspace grapple with
> the complexities of decoding the information it wants from them.
Yes, this would probably be the best generic solution, but in the specific
case of ARM perfevents, the kernel code already has to decode some of the CPU
ID registers to work out what set of events to use. Why make userspace do all
of this decoding again? The x86 code sets up the x86_pmu depending on CPU type
so this is doing a similar thing (although it is easier for x86).

Having perf do all of this decoding for all of the supported CPU types when
the kernel has already done it once and maintaining 2 sets of event lists
seems a bit fiddly compared to simply exporting the supported events from the
kernel...

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