public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Masami Hiramatsu <mhiramat@redhat.com>,
	     Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
	     Peter Zijlstra <peterz@infradead.org>,
	     "Frank Ch. Eigler" <fche@redhat.com>,
	Ingo Molnar <mingo@elte.hu>,
	     LKML <linux-kernel@vger.kernel.org>,
	     systemtap-ml <systemtap@sources.redhat.com>,
	Hideo AOKI <haoki@redhat.com>
Subject: Re: [RFC][Patch 2/2] markers: example of irq regular kernel markers
Date: Sat, 21 Jun 2008 18:04:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.58.0806211013300.32694@gandalf.stny.rr.com> (raw)
In-Reply-To: <20080621190132.E835.KOSAKI.MOTOHIRO@jp.fujitsu.com>


On Sat, 21 Jun 2008, KOSAKI Motohiro wrote:
> >
> > even though, I think you can do that by adding below string table
> > to LTTng module.
> >
> > const char *lookup_table[MAX_MARKERS][2] = {
> > {"irq_entry", "%d %d"}, // or "(int irq_id, int kernel_mode)", "%d %d"
> > ...
> > };
>
> if move string to out of kernel core, compiler may kill some variable.
> thus, we will get incomplete tracing result.

I don't understand why the compiler would do such a thing? The compiler
shouldn't be removing parameters.

>
> I think your proposal is very interesting.
> but I dont understand why someone dislike format strings.
> Could you explain this reason?

Format strings only help for printf like operations. Not all tracers want
such a thing. The best example of this is the sched_switch code. LTTng and
friends just want a pid and comm to show. But there's tracers that want
more info from the task_struct. We also like to see the priority of the
task.

I also foresee these trace hooks be use for dynamic itegrity checks. On
switching out a process we might want to examine both the next and prev to
make sure the context switch should really occur.

There's other places in the core kernel that a tracer wants more than some
data in a structure. Recording all the data that might be needed in a
structure slows down those tracers that only want a little bit of data.
Passing in a pointer to the structure being traced should be enough for
all tracers.

If those that don't care about priority of a context switch, why should it
be parsing it out just for a single tracer that might need it. But all
tracers would need the prev and next pointers.

Now back to your question, why don't we like the printf format. Simply
because it does nothing for pointers. It might help you with a %d and
number of parameters, but a %p can not tell the difference between a
struct tasks_struct *, and a int *, which can have even more devastating
results. It also just looks like a debug session instead of a trace
marker.

Not to mention what Peter Zijlstra already stated, that a printf format
gives only run time checking, where we would like to see compile time
checking.

-- Steve

  reply	other threads:[~2008-06-21 14:36 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-20 19:36 Masami Hiramatsu
2008-06-20 22:16 ` Mathieu Desnoyers
2008-06-20 23:23   ` Masami Hiramatsu
2008-06-21 15:08     ` KOSAKI Motohiro
2008-06-21 18:04       ` Steven Rostedt [this message]
2008-06-21 19:41         ` Frank Ch. Eigler
2008-06-22  4:03           ` Steven Rostedt
2008-06-22  4:32             ` Peter Zijlstra
2008-06-22 17:12               ` Frank Ch. Eigler
2008-06-23  2:20                 ` Masami Hiramatsu
2008-06-23  7:08                   ` KOSAKI Motohiro
2008-06-22 18:03             ` Frank Ch. Eigler
2008-06-22 18:27       ` Masami Hiramatsu
2008-06-21 10:14   ` Peter Zijlstra
2008-06-23  3:06     ` [RFC] Tracepoint proposal Mathieu Desnoyers
2008-06-23  6:34       ` Alexey Dobriyan
2008-06-23  6:51         ` Mathieu Desnoyers
2008-06-24  7:15           ` Alexey Dobriyan
2008-06-24 11:39             ` Masami Hiramatsu
2008-06-24 13:23               ` Takashi Nishiie
2008-06-24 16:23                 ` Frank Ch. Eigler
2008-06-24 19:43                 ` Masami Hiramatsu
2008-06-25  1:08                   ` KOSAKI Motohiro
2008-06-25  1:36                     ` Masami Hiramatsu
2008-06-25  1:49                       ` Mathieu Desnoyers
2008-06-26 16:20                       ` [RFC PATCH] Tracepoint sched probes Mathieu Desnoyers
2008-06-26 17:01                       ` [RFC PATCH] Kernel Tracepoints Mathieu Desnoyers
2008-06-27 13:21                         ` Masami Hiramatsu
2008-06-27 15:00                           ` Mathieu Desnoyers
2008-06-29 18:46                             ` Masami Hiramatsu
2008-06-30 18:21                               ` Mathieu Desnoyers
2008-06-27 15:07                           ` Mathieu Desnoyers
2008-06-30 20:11                             ` Masami Hiramatsu
2008-06-27 15:48                           ` Mathieu Desnoyers
2008-06-28  0:05                             ` Masami Hiramatsu
2008-06-30 17:14                               ` Mathieu Desnoyers
2008-06-30 20:17                                 ` Masami Hiramatsu
2008-07-03 15:13                                   ` Mathieu Desnoyers
2008-07-03 18:53                                     ` Masami Hiramatsu
2008-06-27 16:11                           ` [RFC PATCH] Kernel Tracepoints (update) Mathieu Desnoyers
2008-07-03 15:29                             ` Masami Hiramatsu
2008-07-03 15:47                               ` Mathieu Desnoyers
2008-07-03 18:19                               ` Mathieu Desnoyers
2008-07-03 18:48                                 ` Masami Hiramatsu
2008-06-24 11:06       ` [RFC] Tracepoint proposal Masami Hiramatsu

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=Pine.LNX.4.58.0806211013300.32694@gandalf.stny.rr.com \
    --to=rostedt@goodmis.org \
    --cc=fche@redhat.com \
    --cc=haoki@redhat.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mhiramat@redhat.com \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=systemtap@sources.redhat.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).