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: <20111225174613.GA12732@thunk.org>
Date:	Sun, 25 Dec 2011 12:46:13 -0500
From:	Ted Ts'o <tytso@....edu>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Greg KH <greg@...ah.com>,
	devel@...verdev.osuosl.org, Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, lttng-dev@...ts.lttng.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: Perf ABI (was: Re: [lttng-dev] [PATCH 09/11] sched: export
 task_prio to GPL modules)

On Fri, Dec 23, 2011 at 01:16:41PM -0500, Mathieu Desnoyers wrote:
> 
> (note that ABI to control the tracer and ABI to transport data could
> share the same version numbering if the control tools and transport
> tools happen to reside in the same user-level packages)

Being able to control the tracer but then not being able to look at
the trace output is useless.  So they might as well be the same
thing....

> - The trace data format
>   - Both versioned _and_ self-described.
>   Self-description of the event/field layout allows the same tools to
>   understand traces gathered on different kernel versions, on different
>   architectures, with different tracer configurations.
>   Versioning on top of the self-described trace format allows changes
>   to what the trace self-description can express.

So there are two ways to do this.  One is to make changes be backwards
compatible, so that the trace data format only breaks if you use the
new feature; if it doesn't you encode things the old fashioned way.
The other way of doing things is to randomly break users whenever the
tracing developers decide to add some random new feature, regardless
of whether or not a partiuclar user finds that new feature to be
useful.

The first is acceptable.  The second, IMHO, is not.  Linus has said
quite strongly that WE DO NOT BREAK USERSPACE.   Period.

Regards,

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ