From: Peter Zijlstra <peterz@infradead.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@elte.hu>, Greg KH <gregkh@suse.de>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Frederic Weisbecker <fweisbec@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Theodore Tso <tytso@mit.edu>,
Arjan van de Ven <arjan@infradead.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Lin Ming <ming.m.lin@intel.com>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [RFC][PATCH 1/5] [PATCH 1/5] events: Add EVENT_FS the event filesystem
Date: Wed, 17 Nov 2010 16:35:50 +0100 [thread overview]
Message-ID: <1290008150.2109.953.camel@laptop> (raw)
In-Reply-To: <1290007019.30543.65.camel@gandalf.stny.rr.com>
On Wed, 2010-11-17 at 10:16 -0500, Steven Rostedt wrote:
> What about a tool that picks up tracepoints that were only used by a
> developer for in-field debugging, and then that tracepoint disappears
> because of a design change. Is it OK for that tool to break with it?
>
> Do all tools that use tracepoints require a "check" feature?
Not sure what you mean with a 'check' feature, but I do think its useful
to tools authors to clearly delineate between stable and debug
tracepoints, that also facilitates
> I guess the problem is that creators of the tools to analyze the kernel
> have no idea of what they can count on and what they can't. Do we need a
> process to have these tool creators request to developers to "keep this
> tracepoint"?
the process mentioned here, if they cannot find the data they want
through existing stable tracepoints they have to request it, or
otherwise clearly suffer breakage whenever we feel like changing stuff.
A nice aspect of devs coming to us and requesting data is that we get a
fairly good idea of what tools are available and get to discuss the
problem they're trying to solve.
Esp. that latter point is a very good one imho, we might have a totally
different view on some of the problems :-)
next prev parent reply other threads:[~2010-11-17 15:36 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-17 0:53 [RFC][PATCH 0/5] tracing/events: stable tracepoints Steven Rostedt
2010-11-17 0:53 ` [RFC][PATCH 1/5] [PATCH 1/5] events: Add EVENT_FS the event filesystem Steven Rostedt
2010-11-17 3:32 ` Greg KH
2010-11-17 10:39 ` Ingo Molnar
2010-11-17 12:25 ` Steven Rostedt
2010-11-17 15:03 ` Ingo Molnar
2010-11-17 15:16 ` Peter Zijlstra
2010-11-17 15:16 ` Steven Rostedt
2010-11-17 15:35 ` Peter Zijlstra [this message]
2010-11-17 18:42 ` Ted Ts'o
2010-11-17 15:16 ` Peter Zijlstra
2010-11-23 21:29 ` Steven Rostedt
2010-11-17 17:46 ` Mathieu Desnoyers
2010-11-17 17:52 ` Steven Rostedt
2010-11-17 18:12 ` Mathieu Desnoyers
2010-11-18 9:42 ` Avi Kivity
2010-11-17 23:48 ` Ted Ts'o
2010-11-18 13:05 ` Mathieu Desnoyers
2010-11-17 12:16 ` Steven Rostedt
2010-11-17 0:53 ` [RFC][PATCH 2/5] [PATCH 2/5] tracing/events: Add code to (un)register stable events Steven Rostedt
2010-11-17 0:54 ` [RFC][PATCH 3/5] [PATCH 3/5] tracing/events: Add infrastructure to show stable event formats Steven Rostedt
2010-11-17 0:54 ` [RFC][PATCH 4/5] [PATCH 4/5] tracing/events: Add stable event sched_switch Steven Rostedt
2010-11-17 0:54 ` [RFC][PATCH 5/5] [PATCH 5/5] tracing/events: Add sched_migrate_task stable event Steven Rostedt
2010-11-17 20:14 ` [RFC][PATCH 0/5] tracing/events: stable tracepoints Mathieu Desnoyers
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=1290008150.2109.953.camel@laptop \
--to=peterz@infradead.org \
--cc=acme@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=fweisbec@gmail.com \
--cc=gregkh@suse.de \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=ming.m.lin@intel.com \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox