public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>, Steven Rostedt <rostedt@goodmis.org>,
	lkml <linux-kernel@vger.kernel.org>,
	systemtap <systemtap@sources.redhat.com>,
	kvm <kvm@vger.kernel.org>,
	DLE <dle-develop@lists.sourceforge.net>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Christoph Hellwig <hch@infradead.org>,
	Tom Zanussi <tzanussi@gmail.com>
Subject: Re: [PATCH -tip -v10 7/7] tracing: add kprobe-based event tracer
Date: Tue, 7 Jul 2009 22:58:51 +0200	[thread overview]
Message-ID: <20090707205851.GF6184@nowhere> (raw)
In-Reply-To: <4A53B338.4060803@redhat.com>

On Tue, Jul 07, 2009 at 04:42:32PM -0400, Masami Hiramatsu wrote:
> Frederic Weisbecker wrote:
> > On Tue, Jul 07, 2009 at 03:55:28PM -0400, Masami Hiramatsu wrote:
> >> Frederic Weisbecker wrote:
> >>>> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> >>>> index 206cb7d..65945eb 100644
> >>>> --- a/kernel/trace/trace.h
> >>>> +++ b/kernel/trace/trace.h
> >>>> @@ -45,6 +45,8 @@ enum trace_type {
> >>>>  	TRACE_POWER,
> >>>>  	TRACE_BLK,
> >>>>  	TRACE_KSYM,
> >>>> +	TRACE_KPROBE,
> >>>> +	TRACE_KRETPROBE,
> >>>>  
> >>>>  	__TRACE_LAST_TYPE,
> >>>>  };
> >>>> @@ -227,6 +229,22 @@ struct trace_ksym {
> >>>>  	char			ksym_name[KSYM_NAME_LEN];
> >>>>  	char			p_name[TASK_COMM_LEN];
> >>>>  };
> >>>> +#define TRACE_KPROBE_ARGS 6
> >>>> +
> >>>> +struct kprobe_trace_entry {
> >>>> +	struct trace_entry	ent;
> >>>> +	unsigned long		ip;
> >>>> +	int			nargs;
> >>>> +	unsigned long		args[TRACE_KPROBE_ARGS];
> >>>
> >>>
> >>> I see that you actually make use of arg as a dynamic sizeable
> >>> array.
> >>> For clarity, args[TRACE_KPROBE_ARGS] could be args[0].
> >>>
> >>> It's just a neat and wouldn't affect the code nor the data
> >>> but would be clearer for readers of that code.
> >> Hmm. In that case, I think we'll need a new macro for field
> >> definition, like TRACE_FIELD_ZERO(type, item).
> > 
> > 
> > 
> > You mean that for trace_define_field() to describe fields of events?
> > Actually the fields should be defined dynamically depending on how
> > is built the kprobe event (which arguments are requested, how many,
> > etc..).
> 
> Yeah, if you specified a probe point with its event name, the tracer
> will make a corresponding event dynamically. There are also anonymous
> probes which don't have corresponding events. For those anonymous
> probes, I need to define two generic event types(kprobe and kretprobe).
> 
> Thank you,


Ok. Btw, why do you need to define those two anonymous events?
Actually your event types are always dynamically created.
Those you defined through TRACE_FORMAT_EVENT are only "ghost events",
they only stand there as a abstract pattern, right?


  reply	other threads:[~2009-07-07 20:58 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-01  1:08 [PATCH -tip -v10 0/7] tracing: kprobe-based event tracer and x86 instruction decoder Masami Hiramatsu
2009-07-01  1:08 ` [PATCH -tip -v10 1/7] x86: instruction decoder API Masami Hiramatsu
2009-07-01  1:08 ` [PATCH -tip -v10 2/7] x86: x86 instruction decoder build-time selftest Masami Hiramatsu
2009-07-01  1:09 ` [PATCH -tip -v10 3/7] kprobes: checks probe address is instruction boudary on x86 Masami Hiramatsu
2009-07-01  1:09 ` [PATCH -tip -v10 4/7] kprobes: cleanup fix_riprel() using insn decoder " Masami Hiramatsu
2009-07-01  1:09 ` [PATCH -tip -v10 5/7] x86: add pt_regs register and stack access APIs Masami Hiramatsu
2009-07-06  1:42   ` Frederic Weisbecker
2009-07-06 14:34   ` Andi Kleen
2009-07-06 19:28     ` Masami Hiramatsu
2009-07-06 20:06       ` Andi Kleen
2009-07-07  0:07         ` Masami Hiramatsu
2009-07-01  1:09 ` [PATCH -tip -v10 6/7] tracing: ftrace dynamic ftrace_event_call support Masami Hiramatsu
2009-07-06  1:59   ` Frederic Weisbecker
2009-07-01  1:09 ` [PATCH -tip -v10 7/7] tracing: add kprobe-based event tracer Masami Hiramatsu
2009-07-07  7:31   ` Frederic Weisbecker
2009-07-07 19:55     ` Masami Hiramatsu
2009-07-07 20:20       ` Frederic Weisbecker
2009-07-07 20:42         ` Masami Hiramatsu
2009-07-07 20:58           ` Frederic Weisbecker [this message]
2009-07-07 21:31             ` Masami Hiramatsu
2009-07-07 21:34               ` Frederic Weisbecker
2009-07-07 21:42                 ` Masami Hiramatsu
2009-07-07 22:00                   ` 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=20090707205851.GF6184@nowhere \
    --to=fweisbec@gmail.com \
    --cc=ananth@in.ibm.com \
    --cc=dle-develop@lists.sourceforge.net \
    --cc=hch@infradead.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@redhat.com \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    --cc=systemtap@sources.redhat.com \
    --cc=tzanussi@gmail.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