All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Dave Chinner <david@fromorbit.com>
Cc: Jan Kara <jack@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	Matthew Wilcox <mawilcox@microsoft.com>,
	linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org,
	Steven Rostedt <rostedt@goodmis.org>,
	Christoph Hellwig <hch@lst.de>,
	linux-mm@kvack.org, Ingo Molnar <mingo@redhat.com>,
	linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing
Date: Fri, 25 Nov 2016 07:37:47 +0000	[thread overview]
Message-ID: <20161125073747.GU1555@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20161125070642.GZ31101@dastard>

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

WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Dave Chinner <david@fromorbit.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@lst.de>,
	Dan Williams <dan.j.williams@intel.com>,
	Ingo Molnar <mingo@redhat.com>, Jan Kara <jack@suse.cz>,
	Matthew Wilcox <mawilcox@microsoft.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, linux-nvdimm@ml01.01.org,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing
Date: Fri, 25 Nov 2016 07:37:47 +0000	[thread overview]
Message-ID: <20161125073747.GU1555@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20161125070642.GZ31101@dastard>

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.

WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Dave Chinner <david@fromorbit.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@lst.de>,
	Dan Williams <dan.j.williams@intel.com>,
	Ingo Molnar <mingo@redhat.com>, Jan Kara <jack@suse.cz>,
	Matthew Wilcox <mawilcox@microsoft.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, linux-nvdimm@lists.01.org,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing
Date: Fri, 25 Nov 2016 07:37:47 +0000	[thread overview]
Message-ID: <20161125073747.GU1555@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20161125070642.GZ31101@dastard>

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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Dave Chinner <david@fromorbit.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@lst.de>,
	Dan Williams <dan.j.williams@intel.com>,
	Ingo Molnar <mingo@redhat.com>, Jan Kara <jack@suse.cz>,
	Matthew Wilcox <mawilcox@microsoft.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, linux-nvdimm@lists.01.org,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing
Date: Fri, 25 Nov 2016 07:37:47 +0000	[thread overview]
Message-ID: <20161125073747.GU1555@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20161125070642.GZ31101@dastard>

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.

  reply	other threads:[~2016-11-25  7:38 UTC|newest]

Thread overview: 124+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-23 18:44 [PATCH 0/6] introduce DAX tracepoint support Ross Zwisler
2016-11-23 18:44 ` Ross Zwisler
2016-11-23 18:44 ` Ross Zwisler
2016-11-23 18:44 ` [PATCH 1/6] dax: fix build breakage with ext4, dax and !iomap Ross Zwisler
2016-11-23 18:44   ` Ross Zwisler
2016-11-23 18:44   ` Ross Zwisler
2016-11-24  9:02   ` Jan Kara
2016-11-24  9:02     ` Jan Kara
2016-11-24  9:02     ` Jan Kara
2016-11-24  9:02     ` Jan Kara
2016-11-28 19:15     ` Ross Zwisler
2016-11-28 19:15       ` Ross Zwisler
2016-11-28 19:15       ` Ross Zwisler
2016-11-29  8:53       ` Jan Kara
2016-11-29  8:53         ` Jan Kara
2016-11-29  8:53         ` Jan Kara
2016-11-29  8:53         ` Jan Kara
2016-11-30 19:04         ` Ross Zwisler
2016-11-30 19:04           ` Ross Zwisler
2016-11-30 19:04           ` Ross Zwisler
2016-11-30 19:04           ` Ross Zwisler
2016-12-01  7:53           ` Jan Kara
2016-12-01  7:53             ` Jan Kara
2016-12-01  7:53             ` Jan Kara
2016-12-01  7:53             ` Jan Kara
2016-11-23 18:44 ` [PATCH 2/6] dax: remove leading space from labels Ross Zwisler
2016-11-23 18:44   ` Ross Zwisler
2016-11-23 18:44   ` Ross Zwisler
2016-11-24  9:11   ` Jan Kara
2016-11-24  9:11     ` Jan Kara
2016-11-24  9:11     ` Jan Kara
2016-11-24 19:42     ` Dan Williams
2016-11-24 19:42       ` Dan Williams
2016-11-24 19:42       ` Dan Williams
2016-11-28 19:20       ` Ross Zwisler
2016-11-28 19:20         ` Ross Zwisler
2016-11-28 19:20         ` Ross Zwisler
2016-11-23 18:44 ` [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing Ross Zwisler
2016-11-23 18:44   ` Ross Zwisler
2016-11-23 18:44   ` Ross Zwisler
2016-11-23 18:44   ` Ross Zwisler
2016-11-24  9:16   ` Jan Kara
2016-11-24  9:16     ` Jan Kara
2016-11-24  9:16     ` Jan Kara
2016-11-24  9:16     ` Jan Kara
2016-11-24 17:32   ` Al Viro
2016-11-24 17:32     ` Al Viro
2016-11-24 17:32     ` Al Viro
2016-11-24 17:32     ` Al Viro
2016-11-25  2:49     ` Dave Chinner
2016-11-25  2:49       ` Dave Chinner
2016-11-25  2:49       ` Dave Chinner
2016-11-25  2:49       ` Dave Chinner
2016-11-25  4:14       ` Al Viro
2016-11-25  4:14         ` Al Viro
2016-11-25  4:14         ` Al Viro
2016-11-25  4:14         ` Al Viro
2016-11-25  7:06         ` Dave Chinner
2016-11-25  7:06           ` Dave Chinner
2016-11-25  7:06           ` Dave Chinner
2016-11-25  7:06           ` Dave Chinner
2016-11-25  7:37           ` Al Viro [this message]
2016-11-25  7:37             ` Al Viro
2016-11-25  7:37             ` Al Viro
2016-11-25  7:37             ` Al Viro
2016-11-25 19:51             ` Linus Torvalds
2016-11-25 19:51               ` Linus Torvalds
2016-11-25 19:51               ` Linus Torvalds
2016-11-25 20:36               ` Mike Marshall
2016-11-25 20:36                 ` Mike Marshall
2016-11-25 20:36                 ` Mike Marshall
2016-11-25 21:48               ` Theodore Ts'o
2016-11-25 21:48                 ` Theodore Ts'o
2016-11-25 21:48                 ` Theodore Ts'o
2016-11-25 23:38                 ` Linus Torvalds
2016-11-25 23:38                   ` Linus Torvalds
2016-11-25 23:38                   ` Linus Torvalds
2016-11-28  8:33                 ` Jan Kara
2016-11-28  8:33                   ` Jan Kara
2016-11-28  8:33                   ` Jan Kara
2016-11-27 22:42               ` Dave Chinner
2016-11-27 22:42                 ` Dave Chinner
2016-11-27 22:42                 ` Dave Chinner
2016-11-28  0:58                 ` Linus Torvalds
2016-11-28  0:58                   ` Linus Torvalds
2016-11-28  0:58                   ` Linus Torvalds
2016-11-28  1:45                   ` Al Viro
2016-11-28  1:45                     ` Al Viro
2016-11-28  9:09                   ` Dave Chinner
2016-11-28  9:09                     ` Dave Chinner
2016-11-28  9:09                     ` Dave Chinner
2016-11-25  3:00   ` Dave Chinner
2016-11-25  3:00     ` Dave Chinner
2016-11-25  3:00     ` Dave Chinner
2016-11-28 22:46     ` Ross Zwisler
2016-11-28 22:46       ` Ross Zwisler
2016-11-28 22:46       ` Ross Zwisler
2016-11-28 22:46       ` Ross Zwisler
2016-11-29  2:02       ` Dave Chinner
2016-11-29  2:02         ` Dave Chinner
2016-11-29  2:02         ` Dave Chinner
2017-03-08 22:05         ` Mike Marshall
2017-03-08 22:05           ` Mike Marshall
2017-03-08 22:05           ` Mike Marshall
2017-03-08 22:05           ` Mike Marshall
2016-11-23 18:44 ` [PATCH 4/6] dax: update MAINTAINERS entries for FS DAX Ross Zwisler
2016-11-23 18:44   ` Ross Zwisler
2016-11-23 18:44   ` Ross Zwisler
2016-11-23 18:44   ` Ross Zwisler
2016-11-23 18:44 ` [PATCH 5/6] dax: add tracepoints to dax_pmd_load_hole() Ross Zwisler
2016-11-23 18:44   ` Ross Zwisler
2016-11-23 18:44   ` Ross Zwisler
2016-11-23 18:44   ` Ross Zwisler
2016-11-24  9:20   ` Jan Kara
2016-11-24  9:20     ` Jan Kara
2016-11-24  9:20     ` Jan Kara
2016-11-23 18:44 ` [PATCH 6/6] dax: add tracepoints to dax_pmd_insert_mapping() Ross Zwisler
2016-11-23 18:44   ` Ross Zwisler
2016-11-23 18:44   ` Ross Zwisler
2016-11-23 18:44   ` Ross Zwisler
2016-11-24  9:22   ` Jan Kara
2016-11-24  9:22     ` Jan Kara
2016-11-24  9:22     ` Jan Kara
2016-11-24  9:22     ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161125073747.GU1555@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=david@fromorbit.com \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=mawilcox@microsoft.com \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.