From: "Frank Ch. Eigler" <fche@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <peterz@infradead.org>,
Randy Dunlap <randy.dunlap@oracle.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org, zippel@linux-m68k.org,
linux-kbuild@vger.kernel.org
Subject: Re: [PATCH] tracing/markers: make markers select tracepoints
Date: Tue, 24 Feb 2009 08:01:13 -0500 [thread overview]
Message-ID: <20090224130113.GA6749@redhat.com> (raw)
In-Reply-To: <20090223172302.GB29344@elte.hu>
Hi -
> > The impression that this is somehow different with tracepoints
> > is mistaken. Tracepoints are *exactly* as "ABI-like" as
> > markers.
>
> they arent. To the kernel they look like function calls, with no
> ABI properties at all. They can and will change without notice.
Markers also "look like" function calls because they are - the
callbacks just happen to take a format string and varargs. What did
you think they were?
srostedt argues that separating the tracepoint from its rendering is
necessary to free the instrumentation site from backward-compatibility
stagnation.
But consider - it has been manifold stated that tracepoints are not
welcome in the tree without a "tracer" (hand-written glue), so the
same person ends up writing both. Since they are tightly coupled. a
change on one will affect the other. A moved tracepoint will produce
events at different times; a lost tracepoint parameter will lose data
at trace rendering time. The tracing engine can only pretend to
produce the same data by guessing.
Similarly, if a marker site were to change, and if someone deemed the
old trace data important to preserve, a hand-written marker callback
function could replace a generic one, The new one could make the same
heuristic adaptation.
Try working out some examples. You'll probably see how similar they
really turn out, with respect to the hypothetical "preserve ABI" idea.
- FChE
next prev parent reply other threads:[~2009-02-24 13:01 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-20 16:34 [PATCH] tracing/markers: make markers select tracepoints Frederic Weisbecker
2009-02-20 16:59 ` Randy Dunlap
2009-02-20 17:20 ` Frederic Weisbecker
2009-02-20 17:22 ` Ingo Molnar
2009-02-20 17:29 ` Randy Dunlap
2009-02-20 17:31 ` Frederic Weisbecker
2009-02-20 17:48 ` Ingo Molnar
2009-02-20 18:56 ` Jason Baron
2009-02-21 3:15 ` Frederic Weisbecker
2009-02-21 22:04 ` Frank Ch. Eigler
2009-02-22 17:13 ` Ingo Molnar
2009-02-22 17:38 ` Frank Ch. Eigler
2009-02-23 10:13 ` Avi Kivity
2009-02-22 3:23 ` KOSAKI Motohiro
2009-02-22 11:37 ` Peter Zijlstra
2009-02-22 16:04 ` Mathieu Desnoyers
2009-02-22 19:17 ` Ingo Molnar
2009-02-23 2:47 ` Mathieu Desnoyers
2009-02-23 8:52 ` Ingo Molnar
2009-02-22 11:43 ` Peter Zijlstra
2009-02-22 12:08 ` Frank Ch. Eigler
2009-02-22 12:14 ` Peter Zijlstra
2009-02-22 12:24 ` Frank Ch. Eigler
2009-02-23 11:11 ` Peter Zijlstra
2009-02-23 15:44 ` Frank Ch. Eigler
2009-02-23 16:22 ` Peter Zijlstra
2009-02-23 17:10 ` Frank Ch. Eigler
2009-02-23 17:23 ` Ingo Molnar
2009-02-24 13:01 ` Frank Ch. Eigler [this message]
2009-02-23 17:31 ` Steven Rostedt
2009-02-23 18:32 ` Theodore Tso
2009-02-23 22:16 ` Peter Zijlstra
2009-02-23 22:41 ` Theodore Tso
2009-02-24 8:55 ` Peter Zijlstra
2009-02-23 0:23 ` Steven Rostedt
2009-02-21 5:24 ` [PATCH][RFC] check for select dependency errors on config load Steven Rostedt
2009-02-21 5:58 ` Andrew Morton
2009-02-21 6:08 ` Andrew Morton
2009-02-21 6:20 ` Randy Dunlap
2009-02-21 20:07 ` Steven Rostedt
2009-02-21 20:46 ` [PATCH v2] kconfig: " Steven Rostedt
2009-02-21 20:48 ` Steven Rostedt
2009-02-21 21:51 ` Sam Ravnborg
2009-02-21 21:53 ` Steven Rostedt
2009-02-22 16:23 ` [PATCH][RFC] " Ingo Molnar
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=20090224130113.GA6749@redhat.com \
--to=fche@redhat.com \
--cc=fweisbec@gmail.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=randy.dunlap@oracle.com \
--cc=rostedt@goodmis.org \
--cc=zippel@linux-m68k.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.