linux-kernel - Re: re-enable Nehalem raw Offcore-Events support

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: <20110429221642.GA10751@liondog.tnic>
Date:	Sat, 30 Apr 2011 00:16:42 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Vince Weaver <vweaver1@...s.utk.edu>
Cc:	Ingo Molnar <mingo@...e.hu>, torvalds@...ux-foundation.org,
	linux-kernel@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>,
	Stephane Eranian <eranian@...il.com>,
	Andi Kleen <ak@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: re-enable Nehalem raw Offcore-Events support

On Fri, Apr 29, 2011 at 06:42:27PM +0200, Ingo Molnar wrote:

[..]

> Basically without proper generalization people get sloppy and go the fast path 
> and export very low level, opaque, unstructured PMU interfaces to user-space 
> and repeat the Oprofile and perfmon tooling mistakes again and again.
> 
>  "Thinking is hard, lets go shopping^W exporting raw ABIs."
> 
> So the perf events policy has always been that while we tolerate raw events 
> (there's nothing bad with offering them once generic events have crystallized 
> out), we only accept them if the *useful* events are first abstracted and 
> generalized out.
> 
> We put structure, proper abstractions and easy tooling *ahead* of the interests 
> of a small group of people who'd rather prefer a lowlevel, opaque hardware 
> channel so that they do not have to *think* about generalization and also 
> perhaps so they do not have to share their selection of events and analysis 
> methods with others ...

Yep, absolutely. Excuse my french but even kernel developers who
can understand perf code don't need to know f*cking magical hex
constants in order to trace a little. And yes, we talk about perf
and say how cool it is but users want to see more examples like on
http://perf.wiki.kernel.org - they want to get to use it first _and_
_then_ maybe look at code/more involved scenarios. Other kernel
developers don't give a rat's ass about the possibility for shooting
themselves in the foot - they want to use this thing without reading
code and CPU documentation for a day first. And I believe I speak for
the majority when I say so.

We're always bitching about Linux usability and now when it comes down
to yet another case where this can be done right for a change, and perf
people are trying to do something productive, you come waving hands
loudly at Linus with revert requests instead of helping. This is as
productive as trying to shoot yourself in the foot.

-- 
Regards/Gruss,
    Boris.
--
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/