Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932274AbcK1JJc (ORCPT ); Mon, 28 Nov 2016 04:09:32 -0500 Received: from ipmail06.adl2.internode.on.net ([150.101.137.129]:36740 "EHLO ipmail06.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932141AbcK1JJ1 (ORCPT ); Mon, 28 Nov 2016 04:09:27 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgkACvzO1h5LKmvIGdsb2JhbABeGgEBAQECAQEBAQgBAQEBgzgBAQEBAR+BCQFRgnuDeZxLBoEdjCmGPYQVhhsCAgEBAoFzVAECAQEBAQECBgEBAQEBATlFhGgBAQEDATocIwULCAMYCSUPBSUDBxoTiGUHr06LRwEBAQEGAgEkIIVUhSWHeoIwBZpUkHmQP41xhAyBShMMhWUqNIgQAQEB Date: Mon, 28 Nov 2016 20:09:23 +1100 From: Dave Chinner To: Linus Torvalds Cc: Al Viro , Ross Zwisler , Linux Kernel Mailing List , Andrew Morton , Christoph Hellwig , Dan Williams , Ingo Molnar , Jan Kara , Matthew Wilcox , Steven Rostedt , "linux-ext4@vger.kernel.org" , linux-fsdevel , linux-mm , "linux-nvdimm@lists.01.org" Subject: Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing Message-ID: <20161128090923.GB31101@dastard> References: <1479926662-21718-1-git-send-email-ross.zwisler@linux.intel.com> <1479926662-21718-4-git-send-email-ross.zwisler@linux.intel.com> <20161124173220.GR1555@ZenIV.linux.org.uk> <20161125024918.GX31101@dastard> <20161125041419.GT1555@ZenIV.linux.org.uk> <20161125070642.GZ31101@dastard> <20161125073747.GU1555@ZenIV.linux.org.uk> <20161127224208.GA31101@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2546 Lines: 60 On Sun, Nov 27, 2016 at 04:58:43PM -0800, Linus Torvalds wrote: > On Sun, Nov 27, 2016 at 2:42 PM, Dave Chinner wrote: > > > > And that's exactly why we need a method of marking tracepoints as > > stable. How else are we going to know whether a specific tracepoint > > is stable if the kernel code doesn't document that it's stable? > > You are living in some unrealistic dream-world where you think you can > get the right tracepoint on the first try. No, I'm under no illusions that we'd get stable tracepoints right the first go. I don't care about how we stabilise stable tracepoints, because nothing I maintain will use stable tracepoints. However, I will point out that we have /already solved these ABI development problems/. $ ls Documentation/ABI/ obsolete README removed stable testing $ Expands this to include stable tracepoints, not just sysfs files. New stable stuff gets classified as "testing" meaning it is supposed to be stable but may change before being declared officially stable. "stable" is obvious, are "obsolete" and "removed". > So there is no way in hell I would ever mark any tracepoint "stable" > until it has had a fair amount of use, and there are useful tools that > actually make use of it, and it has shown itself to be the right > trace-point. > > And once that actually happens, what's the advantage of marking it > stable? None. It's a catch-22. Before it has uses and has been tested > and found to be good, it's not stable. And after, it's pointless. And that "catch-22" is *precisely the problem we need to solve*. Pointing out that there's a catch-22 doesn't help anyone - all the developers that are telling you that they really need a way to mark stable tracepoints already understand this catch-22 and they want a way to avoid it. Being able to either say "this is stable and we'll support it forever" or "this will never be stable so use at your own risk" is a simple way of avoiding the catch-22. If an unstable tracepoint is useful to applications *and it can be implemented in a maintainable, stable form* then it can go through the process of being made stable and documented in Documentation/ABI/stable. Problem is solved, catch-22 is gone. All we want is some method of making a clear, unambiguous statement about the nature of a specific tracepoint and a process for transitioning a tracepoint to a stable, maintainable form. We do it for other ABI interfaces, so why can't we do this for tracepoints? Cheers, Dave. -- Dave Chinner david@fromorbit.com