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

[Shuah Khan <shuahkhan@gmail.com>]

On Tue, Sep 6, 2016 at 11:30 PM, Andy Lutomirski <luto@kernel.org> wrote:
> 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.

Agreed. Tracepoints and events provide a powerful tool in debug certain class
of problems (races and performance problems) where traditional debug methods
such as CONFIG_DEBUG_FOO aren't effective. Trace information includes important
status information on thread status which is helpful in debugging.

What I find useful is being able enable and disable events during
run-time without
worrying about whether or not  CONFIG_DEBUG_FOO is enabled on the kernel I am
debugging. In some cases, problem becomes disappears when debug is enabled.
In my mind, the kernel itself is different beast and all bets are off
for certain class
of problems.

I am by no means discounting the userspace angle of this issue. I am
looking to see
if we can find a way to use this feature without handicapping ourselves.

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

We can make it clear that tracepoints and events can change with no notice.

thanks,
-- Shuah