On Sep 6, 2016 10:10 PM, "Al Viro" <viro@zeniv.linux.org.uk> wrote:
>
> 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.
>

Agreed.

I wouldn't mind a policy that tracepoints are simply never stable.  Maybe
we should even deliberately change them periodically to drive the point
home.

The kernel should be able to have a debug API that is genuinely for
*debugging* and doesn't freeze the underlying implementation.

Windows, AFAICT, works like this.  If you write a production program that
invokes WinDbg or similar, it's going to break down the road.