linux-kernel - Re: Perf ABI (was: Re: [lttng-dev] [PATCH 09/11] sched: export task

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: <20111223172155.GA14117@thunk.org>
Date:	Fri, 23 Dec 2011 12:21:55 -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 11:46:29AM -0500, Mathieu Desnoyers wrote:
> - It's doing so without even needing it: Perf is using an ABI versioning
>   scheme designed for filesystems, when it is not in fact driven by the
>   same constraints.

Well, there are *some* constraints.  I've been assured that despite
the fact that the perf client is in the kernel sources (something
which I still think is a bad idea, since it's leading to other bad
choices like kvm-tool wanting to be bundled with kernel sources), that
it is *not* a license to jerk the format around wildly --- that people
will have installed userspace binaries that shouldn't randomly break
they boot a new kernel.

So I'm *glad* that Perf is using an ABI versioning scheme that accepts
the same restraints as file systems.  It means we don't randomly break
userspace tools.

So Mathieu, if you think it is the current standards of backwards
compatibility are too rigid, what level of tool breakage do you think
is acceptable?  It's not just about the backwards compatibility of the
trace files, it's also about compatibility of userspace utilities.

For example, systemtap, where you had to recompile from source at
each kernel revision, and pray it would still build goes too far in
the other direction, wouldn't you agree?  What is the correct level of
kernel developer annoyance you think is appropriate to inflict on
ourselves?

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/