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

[Vlastimil Babka <vbabka@suse.cz>]

On 09/07/2016 07:30 AM, Andy Lutomirski wrote:
> On Sep 6, 2016 10:10 PM, "Al Viro" <viro@zeniv.linux.org.uk
> <mailto:viro@zeniv.linux.org.uk>> wrote:
>> 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.

I would wish that as well. Tracepoints sometimes must expose 
implementation details to be useful for debugging *the implementation*. 
The tools that use them to build some extra interesting metrics on top 
the tracepoints may often need to know even more about the 
implementation for correct interpretation of the data.

Even if the kernel implementation changes *without* touching the 
tracepoint format, the changed behavior might still destroy these 
metrics. (I hope it's understandable what I'm trying to say, I can't 
think of a good example right now). Do we want to set the implementation 
in stone to such extent? That would suck. If not, then the only way 
would be to indeed not mainline any tracepoints, which would also suck.

> 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.
>
>
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>