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

[Christian Borntraeger <borntraeger@de.ibm.com>]

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:
>>
>> 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.

In case I will be invited this is certainly a topic that I am interested in.

We faced this challenge as well for our kvm/s390 trace points. Back then
Somebody (Avi?) suggested to provide two classes on trace points (kvm and kvm-s390)
where kvm provides trace points that are a given (HW events) and kvm-s390 is 
implementation specific. The idea was that we can change kvm-s390 and keep kvm.
Now there is a user of these trace points (perf kvm), which actually limits us to
only extend existing trace points (but not changing existing fields) also for
the kvm trace points.

Do we consider userspace under tools as part of the kernel (so we can change 
trace points that are only used by these tools?

Christian

> 
> 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.