[ Added Linus and Al ]

On Thu, 23 May 2019 19:08:51 -0700
Alexei Starovoitov [off-list ref] wrote:

quoted

quoted

quoted

I wish that was totally true, but tracepoints *can* be an abi. I had
code reverted because powertop required one to be a specific
format. To this day, the wakeup event has a "success" field that
writes in a hardcoded "1", because there's tools that depend on it,
and they only work if there's a success field and the value is 1.    

I really think that you should put powertop nightmares to rest.
That was long ago. The kernel is different now.  

Is it?
  

quoted

Linus made it clear several times that it is ok to change _all_
tracepoints. Period. Some maintainers somehow still don't believe
that they can do it.  

From what I remember him saying several times, is that you can change
all tracepoints, but if it breaks a tool that is useful, then that
change will get reverted. He will allow you to go and fix that tool and
bring back the change (which was the solution to powertop).  

my interpretation is different.
We changed tracepoints. It broke scripts. People changed scripts.

Scripts are different than binary tools.

quoted

quoted

Some tracepoints are used more than others and more people will
complain: "ohh I need to change my script" when that tracepoint
changes. But the kernel development is not going to be hampered by a
tracepoint. No matter how widespread its usage in scripts.  

That's because we'll treat bpf (and Dtrace) scripts like modules (no
abi), at least we better. But if there's a tool that doesn't use the
script and reads the tracepoint directly via perf, then that's a
different story.  

absolutely not.
tracepoint is a tracepoint. It can change regardless of what
and how is using it.

Instead of putting words into Linus's mouth, I'll just let him speak
for himself. If a useful tool that reads a tracepoint breaks because we
changed the tracepoint, and Linus is fine with that. Then great, we can
start adding them to VFS and not worry about them being an ABI.

-- Steve