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

[Shuah Khan <shuahkhan@gmail.com>]

On Tue, Sep 6, 2016 at 12:51 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>         Right now there is no mechanism for saying "if this tracepoints
> breaks, it's Not Our Problem(tm)".  All of them are parts of userland
> ABI, potentially casting in stone all kinds of kernel internals.  E.g.
> just today a patch series adding tracepoints to kobject primitives
> had been posted; if _that_ becomes a part of stable ABI, we get the
> lifetime rules for anything with an embedded kobject exposed to userland
> and potentially impossible to change - all it takes is a single piece of
> software making non-trivial use of those.

I honestly didn't think that my patch series will result in a special
KS topic :)
However, I think it is a good idea to discuss it as general topic for
what kind of
kernel information should/should not be made visible via tracepoints or other
debug mechanisms.

We do support a wide range of tracepoints and events in various sub-systems
skb.h, pagemap.h, and pagemap.h so on. Maybe it would be helpful to agree
on some sort of guidelines for exposure.

Guess I never considered tracepoints as userspace API, anymore than debug
messages. It is part of debug and only visible to root.

In my mind it is mainly a debug information that would only make sense to
kernel developers. That is why I didn't think about needing to keep the
tracepoints identical. That said, it is a good idea for us to discuss at the KS.

thanks,
-- Shuah

>
>         Exposing kernel internals to debugging scripts et.al. is fine,
> but only as long as we are promising to keep those scripts working.
> Otherwise we end up promising that arseloads of code we can't even see,
> sticking its fingers very deep into the kernel internals, will be kept
> functional through the kernel changes.  This is absolutely insane, of
> course, and I doubt that anybody would be willing to make such promises,
> no matter how much value would that add.
>
>         The tracepoints are undiffirentiated mass, with no way for userland
> to tell whether it's using something stable or an equivalent of someone's
> debugging printks with no promise of stability.  And folks, there *are*
> people out there with commit priveleges on assorted userland projects who'd
> made it perfectly clear that _any_ kernel interface they find is fair game -
> as in "if you didn't want it used, why did you put it in the kernel?".
> No matter how much I dislike that bunch for other things, I can't blame them
> for being less than upfront regarding that policy.  It had been expressed
> very clearly and we'd better take the warning seriously.
>
>         I think this is something that needs to be discussed at KS; IMO we
> need at least some way to express the degree of stability promises made
> wrt individual tracepoints and some mechanisms for preventing silent creep
> towards full stability; something along the lines of "unstable tracepoint $FOO
> used by $PROGRAM, kernel tainted", at least.
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss