Re: Perf ABI (was: Re: [lttng-dev] [PATCH 09/11] sched: export task_prio to GPL modules)

Ted Ts'o
2011-12-23T17:22:17Z

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