Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753887AbcK0WmS (ORCPT ); Sun, 27 Nov 2016 17:42:18 -0500 Received: from ipmail05.adl6.internode.on.net ([150.101.137.143]:46056 "EHLO ipmail05.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751532AbcK0WmN (ORCPT ); Sun, 27 Nov 2016 17:42:13 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2C9BQDCXztYIK+pLHlWCBoBAQEBAgEBAQEIAQEBAYM4AQEBAQEfgVuGdIZRlXQBAQEBAQEGgR2MKYY9gg6CB4YbAgIBAQKBZUAUAQIBAQEBAQEBBgEBAQEBATlFQhKEFAEBAQMBOhwjBQsIAxgJJQ8FJQMHGhOIZQevKItBAQEBAQYBAQEBIyCFVIUlhCeDU4IwBZpUkHmQP41xhAwegSwTDINYHIFxKjSFa4MKAQEB Date: Mon, 28 Nov 2016 09:42:08 +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: <20161127224208.GA31101@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> 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: 2381 Lines: 53 On Fri, Nov 25, 2016 at 11:51:26AM -0800, Linus Torvalds wrote: > On Thu, Nov 24, 2016 at 11:37 PM, Al Viro wrote: > > > > My impression is that nobody (at least kernel-side) wants them to be > > a stable ABI, so long as nobody in userland screams about their code > > being broken, everything is fine. As usual, if nobody notices an ABI > > change, it hasn't happened. The question is what happens when somebody > > does. > > Right. There is basically _no_ "stable API" for the kernel anywhere, > it's just an issue of "you can't break workflow for normal people". > > And if somebody writes his own trace scripts, and some random trace > point goes away (or changes semantics), that's easy: he can just fix > his script. Tracepoints aren't ever going to be stable in that sense. > > But when then somebody writes a trace script that is so useful that > distros pick it up, and people start using it and depending on it, > then _that_ trace point may well have become effectively locked in > stone. 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? And how are we going to know why it's considered stable if there isn't a commit message that explains why it was made stable? > We do have filesystem code that is just disgusting. As an example: > fs/afs/ tends to have these crazy "_enter()/_exit()" macros in every > single function. If you want that, use the function tracer. That seems > to be just debugging code that has been left around for others to > stumble over. I do *not* believe that we should encourage that kind of > "machine gun spray" use of tracepoints. Inappropriate use of tracepoints is a different problem. The issue here is getting rid of the uncertainty caused by the handwavy "tracepoints a mutable until someone, somewhere decides to use it in userspace" policy. > But tracing actual high-level things like IO and faults? I think that > makes perfect sense, as long as the data that is collected is also the > actual event data, and not so much a random implementation issue of > the day. IME, a tracepoint that doesn't expose detailed context specific information isn't really useful for complex problem diagnosis... Cheers, Dave. -- Dave Chinner david@fromorbit.com