From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [195.92.253.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id E145F81EE5 for ; Thu, 24 Nov 2016 23:38:04 -0800 (PST) Date: Fri, 25 Nov 2016 07:37:47 +0000 From: Al Viro Subject: Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing Message-ID: <20161125073747.GU1555@ZenIV.linux.org.uk> 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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20161125070642.GZ31101@dastard> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Dave Chinner Cc: Jan Kara , Andrew Morton , Matthew Wilcox , linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org, Steven Rostedt , Christoph Hellwig , linux-mm@kvack.org, Ingo Molnar , linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, Linus Torvalds List-ID: On Fri, Nov 25, 2016 at 06:06:42PM +1100, Dave Chinner wrote: > > Tell that to Linus. You had been in the room, IIRC, when that had been > > brought up this year in Santa Fe. > > No, I wasn't at KS or plumbers, so this is all news to me. Sorry, thought you had been at KS ;-/ My apologies... [snip bloody good points I fully agree with] > I understand why there is a desire for stable tracepoints, and > that's why I suggested that there should be an in-kernel API to > declare stable tracepoints. That way we can have the best of both > worlds - tracepoints that applications need to be stable can be > declared, reviewed and explicitly marked as stable in full knowledge > of what that implies. The rest of the vast body of tracepoints can > be left as mutable with no stability or existence guarantees so that > developers can continue to treat them in a way that best suits > problem diagnosis without compromising the future development of the > code being traced. If userspace finds some of those tracepoints > useful, then they can be taken through the process of making them > into a maintainable stable form and being marked as such. 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. > We already have distros mounting the tracing subsystem on > /sys/kernel/tracing. Expose all the stable tracepoints there, and > leave all the other tracepoints under /sys/kernel/debug/tracing. > Simple, clear separation between stable and mutable diagnostic > tracepoints for users, combined with a simple, clear in-kernel API > and process for making tracepoints stable.... Yep. That kind of separation would be my preference as well - ideally, with review for stable ones being a lot less casual that for unstable; AFAICS what happens now is that we have no mechanisms for marking them as stable or unstable and everything keeps going on hope that nobody will cause a mess by creating such a userland dependency. So far it's been mostly working, but as the set of tracepoints (and their use) gets wider and wider, IMO it's only matter of time until we get seriously screwed that way. Basically, we are gambling on the next one to be cast in stone by userland dependency being sane enough to make it possible to maintain it indefinitely and I don't like the odds. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752717AbcKYHiD (ORCPT ); Fri, 25 Nov 2016 02:38:03 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:55898 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752634AbcKYHh5 (ORCPT ); Fri, 25 Nov 2016 02:37:57 -0500 Date: Fri, 25 Nov 2016 07:37:47 +0000 From: Al Viro To: Dave Chinner Cc: Ross Zwisler , linux-kernel@vger.kernel.org, Andrew Morton , Christoph Hellwig , Dan Williams , Ingo Molnar , Jan Kara , Matthew Wilcox , Steven Rostedt , linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@ml01.01.org, Linus Torvalds Subject: Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing Message-ID: <20161125073747.GU1555@ZenIV.linux.org.uk> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161125070642.GZ31101@dastard> User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 25, 2016 at 06:06:42PM +1100, Dave Chinner wrote: > > Tell that to Linus. You had been in the room, IIRC, when that had been > > brought up this year in Santa Fe. > > No, I wasn't at KS or plumbers, so this is all news to me. Sorry, thought you had been at KS ;-/ My apologies... [snip bloody good points I fully agree with] > I understand why there is a desire for stable tracepoints, and > that's why I suggested that there should be an in-kernel API to > declare stable tracepoints. That way we can have the best of both > worlds - tracepoints that applications need to be stable can be > declared, reviewed and explicitly marked as stable in full knowledge > of what that implies. The rest of the vast body of tracepoints can > be left as mutable with no stability or existence guarantees so that > developers can continue to treat them in a way that best suits > problem diagnosis without compromising the future development of the > code being traced. If userspace finds some of those tracepoints > useful, then they can be taken through the process of making them > into a maintainable stable form and being marked as such. 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. > We already have distros mounting the tracing subsystem on > /sys/kernel/tracing. Expose all the stable tracepoints there, and > leave all the other tracepoints under /sys/kernel/debug/tracing. > Simple, clear separation between stable and mutable diagnostic > tracepoints for users, combined with a simple, clear in-kernel API > and process for making tracepoints stable.... Yep. That kind of separation would be my preference as well - ideally, with review for stable ones being a lot less casual that for unstable; AFAICS what happens now is that we have no mechanisms for marking them as stable or unstable and everything keeps going on hope that nobody will cause a mess by creating such a userland dependency. So far it's been mostly working, but as the set of tracepoints (and their use) gets wider and wider, IMO it's only matter of time until we get seriously screwed that way. Basically, we are gambling on the next one to be cast in stone by userland dependency being sane enough to make it possible to maintain it indefinitely and I don't like the odds. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 25 Nov 2016 07:37:47 +0000 From: Al Viro To: Dave Chinner Cc: Ross Zwisler , linux-kernel@vger.kernel.org, Andrew Morton , Christoph Hellwig , Dan Williams , Ingo Molnar , Jan Kara , Matthew Wilcox , Steven Rostedt , linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@lists.01.org, Linus Torvalds Subject: Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing Message-ID: <20161125073747.GU1555@ZenIV.linux.org.uk> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161125070642.GZ31101@dastard> Sender: owner-linux-mm@kvack.org List-ID: On Fri, Nov 25, 2016 at 06:06:42PM +1100, Dave Chinner wrote: > > Tell that to Linus. You had been in the room, IIRC, when that had been > > brought up this year in Santa Fe. > > No, I wasn't at KS or plumbers, so this is all news to me. Sorry, thought you had been at KS ;-/ My apologies... [snip bloody good points I fully agree with] > I understand why there is a desire for stable tracepoints, and > that's why I suggested that there should be an in-kernel API to > declare stable tracepoints. That way we can have the best of both > worlds - tracepoints that applications need to be stable can be > declared, reviewed and explicitly marked as stable in full knowledge > of what that implies. The rest of the vast body of tracepoints can > be left as mutable with no stability or existence guarantees so that > developers can continue to treat them in a way that best suits > problem diagnosis without compromising the future development of the > code being traced. If userspace finds some of those tracepoints > useful, then they can be taken through the process of making them > into a maintainable stable form and being marked as such. 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. > We already have distros mounting the tracing subsystem on > /sys/kernel/tracing. Expose all the stable tracepoints there, and > leave all the other tracepoints under /sys/kernel/debug/tracing. > Simple, clear separation between stable and mutable diagnostic > tracepoints for users, combined with a simple, clear in-kernel API > and process for making tracepoints stable.... Yep. That kind of separation would be my preference as well - ideally, with review for stable ones being a lot less casual that for unstable; AFAICS what happens now is that we have no mechanisms for marking them as stable or unstable and everything keeps going on hope that nobody will cause a mess by creating such a userland dependency. So far it's been mostly working, but as the set of tracepoints (and their use) gets wider and wider, IMO it's only matter of time until we get seriously screwed that way. Basically, we are gambling on the next one to be cast in stone by userland dependency being sane enough to make it possible to maintain it indefinitely and I don't like the odds. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing Date: Fri, 25 Nov 2016 07:37:47 +0000 Message-ID: <20161125073747.GU1555@ZenIV.linux.org.uk> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Ross Zwisler , linux-kernel@vger.kernel.org, Andrew Morton , Christoph Hellwig , Dan Williams , Ingo Molnar , Jan Kara , Matthew Wilcox , Steven Rostedt , linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@lists.01.org, Linus Torvalds To: Dave Chinner Return-path: Content-Disposition: inline In-Reply-To: <20161125070642.GZ31101@dastard> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-ext4.vger.kernel.org On Fri, Nov 25, 2016 at 06:06:42PM +1100, Dave Chinner wrote: > > Tell that to Linus. You had been in the room, IIRC, when that had been > > brought up this year in Santa Fe. > > No, I wasn't at KS or plumbers, so this is all news to me. Sorry, thought you had been at KS ;-/ My apologies... [snip bloody good points I fully agree with] > I understand why there is a desire for stable tracepoints, and > that's why I suggested that there should be an in-kernel API to > declare stable tracepoints. That way we can have the best of both > worlds - tracepoints that applications need to be stable can be > declared, reviewed and explicitly marked as stable in full knowledge > of what that implies. The rest of the vast body of tracepoints can > be left as mutable with no stability or existence guarantees so that > developers can continue to treat them in a way that best suits > problem diagnosis without compromising the future development of the > code being traced. If userspace finds some of those tracepoints > useful, then they can be taken through the process of making them > into a maintainable stable form and being marked as such. 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. > We already have distros mounting the tracing subsystem on > /sys/kernel/tracing. Expose all the stable tracepoints there, and > leave all the other tracepoints under /sys/kernel/debug/tracing. > Simple, clear separation between stable and mutable diagnostic > tracepoints for users, combined with a simple, clear in-kernel API > and process for making tracepoints stable.... Yep. That kind of separation would be my preference as well - ideally, with review for stable ones being a lot less casual that for unstable; AFAICS what happens now is that we have no mechanisms for marking them as stable or unstable and everything keeps going on hope that nobody will cause a mess by creating such a userland dependency. So far it's been mostly working, but as the set of tracepoints (and their use) gets wider and wider, IMO it's only matter of time until we get seriously screwed that way. Basically, we are gambling on the next one to be cast in stone by userland dependency being sane enough to make it possible to maintain it indefinitely and I don't like the odds.