Re: [Ksummit-discuss] [topic proposal] tracepoints and ABI stability warranties

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 7 Sep 2016 00:36:44 +0300
Alexey Dobriyan <adobriyan@gmail.com> wrote:


> The solution was out there for quite some time :-)
> 
> 	Scope of Compatibility
> 	Packages in Red Hat Enterprise Linux are classified under one of
> 	the following four compatibility levels:
> 
> 	[ ] Compatibility level 1: APIs and ABIs are stable across three
> 	    major releases;
> 
> 	[ ] Compatibility level 2: APIs and ABIs are stable within one major
> 	    release.
> 
> 	[ ] Compatibility level 3: Reserved for future use.
> 
> 	[X] Compatibility level 4: No compatibility is provided.
> 
> The winning move is to not play and let distros sort it out.

Except that Linus has a hard rule for this. See the reason behind his
infamous rant:

   https://lkml.org/lkml/2012/12/23/75

Specifically:

 "If a change results in user programs breaking, it's a bug in the
  kernel. We never EVER blame the user programs."


> 
> P.S.: techically every kernel release almost certainly breaks crash(1)
> program, program many people on this list should be familiar with.
> It is unclear why rules should be different for tracepoints.

Well, crash() isn't a userspace tool that runs on top of Linux. Well,
it does, but only the input from a core dump of a Linux kernel breaks
it. It will always run fine on all Linux versions as long as it uses
the same input.

Tracepoints are runtime visible. This isn't a postmortem analysis. We
already had an issues when powertop read the tracepoints directly
without using the tracepoint format file parsing, and we ended up
having 4 bytes of useless data in *every* tracepoint. Luckily, that got
fixed because this hard coding broke when running powertop from a 32
bit userspace on top of a 64 bit kernel. I worked to get powertop to
use the tracepoint format parsing that perf and trace-cmd uses.

But if something depends on event fields, we need to maintain that. For
now, we have fake fields in the sched_wakeup tracepoint, because of
this.

It's a balance that we need to figure out. One is that tracepoints are
really helpful for in the field debugging to see what is happening. The
other is that they are becoming an ABI and if a useful tool (like
powertop) hooks into them, whatever they hooked into becomes set in
stone.

This is a real issue, and has been brought up in past kernel summits
without a resolution.

-- Steve