Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758869AbZGGVfF (ORCPT ); Tue, 7 Jul 2009 17:35:05 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756961AbZGGVey (ORCPT ); Tue, 7 Jul 2009 17:34:54 -0400 Received: from mail-bw0-f225.google.com ([209.85.218.225]:64713 "EHLO mail-bw0-f225.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755086AbZGGVex (ORCPT ); Tue, 7 Jul 2009 17:34:53 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=YsB77Gt63i7AP/eq0Wm0iTnor4zomtc2lVTBCYpgvcLsFYfRTW2sQ09lftPyeIZdo7 TFHC5R4w0wJVll7HJvnczx3u8R0GvH0qfaJkwimXI5dOlx3UksBabHT7rPeL6nXQ7GkB jCS802j3X/u0ilv4XGoYJ19uOkhYLVaDxkwno= Date: Tue, 7 Jul 2009 23:34:48 +0200 From: Frederic Weisbecker To: Masami Hiramatsu Cc: Ingo Molnar , Steven Rostedt , lkml , systemtap , kvm , DLE , Ananth N Mavinakayanahalli , Christoph Hellwig , Tom Zanussi Subject: Re: [PATCH -tip -v10 7/7] tracing: add kprobe-based event tracer Message-ID: <20090707213447.GC7412@nowhere> References: <20090701010838.32547.62843.stgit@localhost.localdomain> <20090701010923.32547.74203.stgit@localhost.localdomain> <20090707073103.GA6173@nowhere> <4A53A830.3000305@redhat.com> <20090707202008.GE6184@nowhere> <4A53B338.4060803@redhat.com> <20090707205851.GF6184@nowhere> <4A53BEAD.7030404@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A53BEAD.7030404@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3163 Lines: 86 On Tue, Jul 07, 2009 at 05:31:25PM -0400, Masami Hiramatsu wrote: > Frederic Weisbecker wrote: > > 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? > > > > Not always created. > > Below command will create an event "event1"; > p probe_point:event1 a1 a2 a3 ... > /debug/tracing/kprobe_events > > But next command doesn't create. > p probe_point a1 a2 a3 ... > /debug/tracing/kprobe_events Aah, ok. > This just inserts a kprobe to probe_point. the advantage of this > "simple" command is that you never be annoyed by making different > name for new events :-) Indeed. But speaking about that, may be you could dynamically create a name following this simple model: func+offset Unless we can set several kprobes on the exact same address? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/