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

[Al Viro <viro@ZenIV.linux.org.uk>]

On Wed, Sep 07, 2016 at 01:41:00AM +0300, Alexey Dobriyan wrote:

> Gentlemen's agreement then:
> * kernel developers don't break tracepoints on purpose and maintain
>   compatibility in simple cases (long => int, deleted field, etc),
> * real, justified tracepoint breakage doesn't count.

No go.  Scenario:

1) piss-poor API is added in form of tracehook.  It exports some information
that can be used to derive something genuinely interesting.  Most of the
time.  Corner cases are unsolvable, even though it might be possible to
provide the interesting part sanely.  Just not in that form.  Moreover,
faking the bits used to derive that information so that existing userland
logics would yield the right result is bloody hard and restricts what we
can do kernel-side, even though the real thing userland wants would not have
such problems.

2) userland code of matching quality is added to a certain daemon.  Tons
of boxen become dependent on that thing _in_ _that_ _shitty_ _form_.

3) you notice the problems kernel-side and make changes that break the damn
thing.

4) daemon authors come complaining.  You refer them to the "gentlemen's
agreement".  They refer you to the Figure 1 and inform you that if you didn't
want that API to be used, you shouldn't have allowed it into the kernel.
Correctly on both counts, at that.  Incidentally, that agreement of yours is
not something they signed upon, and what's that "gentleman" thing anyway?
Linus informs you that you are a particularly obtuse idiot and haven't you
learnt that WE DON'T BREAK USERLAND CODE, DAMNIT by now?

5) you are stuck keeping that turd, no matter the cost.  Adding a replacement
API (sanely designed this time) that would allow to get the same information
is welcome, but it doesn't relieve you from keeping both at least for 5-6
years.

Tracepoints are easy to add for quick debugging/instrumentation/etc. and
that's what makes them useful; OTOH, for a stable API you want more time
going into design and review, or you'll pay a _lot_ more maintaining it.
The thing is, API that has started with no intention to turn it into stable one
might end up become just that.  Your agreement is basically that tracepoints
should never become stable APIs, but that train has left years ago.

One way to deal with that is to refuse to accept any tracepoints in the area
you maintain.  Another might be to differentiate between stable and unstable
ones, with much more review for the former and a very explicit "if you
ever want to use that for more than one kernel version, you get to keep it
working yourself" about the latter.  But that only works if it's visible to
userland *and* Linus agrees that anything of that sort will not get the
normal stable API treatment, i.e. "real code uses it, you get to keep it
working".