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  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, 17 Nov 2010 16:03:32 +0100
From:	Ingo Molnar <>
To:	Steven Rostedt <>
Cc:	Greg KH <>,,
	Andrew Morton <>,
	Thomas Gleixner <>,
	Peter Zijlstra <>,
	Frederic Weisbecker <>,
	Linus Torvalds <>,
	Theodore Tso <>,
	Arjan van de Ven <>,
	Mathieu Desnoyers <>,
	Lin Ming <>,
	Arnaldo Carvalho de Melo <>,
	Peter Zijlstra <>
Subject: Re: [RFC][PATCH 1/5] [PATCH 1/5] events: Add EVENT_FS the event

* Steven Rostedt <> wrote:

> Are these events now going to be labeled as stable?  Is every tracepoint we have, 
> much have the same data?  Linus specifically said at Kernel Summit that he wants 
> absolutely NO modules to have a stable tracepoint.

I think you are worrying about the wrong things.

I think Arjan's complaints at the KS stemmed from prior sporadic declarations on 
lkml that there is no tracepoint ABI _at all_, and that powertop/latencytop could 
break anytime.

But in reality i strongly disagree with such declarations, and tracepoint data that 
is used by PowerTop/timechart/latencytop or perf is and was an ABI, simple as that - 
and i've been enforcing that for two years. (We have so few good instrumentation 
tools that we _really_ dont want to break them.)

At that point, realizing that we have an ABI for existing tools, i think it's 
fundamentally misguided to go out on a limb trying to put barriers in the way of 
other tools that do not even exist to begin with ...

Our real problem with tracing is lack of relevance, lack of utility, lack of 
punch-through analytical power.

Trying to create a sandbox to _reduce utility_ is like the last step, and a really 
optional step, when we have such variety that we want some control over it. It's 
always expensive, it always reduces the tool space as collateral damage.

So please dont think of sysfs or eventfs as a tool to restrict. Think of it as a 
tool to _organize_.

Again, i'd _LOVE_ to have the 'problem' of us having so many tools that analyze 
application and kernel behavior in such a rich way that they use tracepoints that 
were not supposed to be 'stable'.

I simply dont see the 'problem' that is being solved here. We had a stable ABI and 
we didnt break sysprof or powertop/latencytop in the past and wont break it in the 
future either.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists