From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18572 invoked by alias); 21 Jun 2008 14:36:46 -0000 Received: (qmail 18561 invoked by uid 22791); 21 Jun 2008 14:36:45 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from hrndva-omtalb.mail.rr.com (HELO hrndva-omtalb.mail.rr.com) (71.74.56.125) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 21 Jun 2008 14:36:26 +0000 Received: from gandalf ([74.74.65.243]) by hrndva-omta06.mail.rr.com with ESMTP id <20080621143624.TPAF2616.hrndva-omta06.mail.rr.com@gandalf>; Sat, 21 Jun 2008 14:36:24 +0000 Date: Sat, 21 Jun 2008 18:04:00 -0000 From: Steven Rostedt X-X-Sender: rostedt@gandalf.stny.rr.com To: KOSAKI Motohiro cc: Masami Hiramatsu , Mathieu Desnoyers , Peter Zijlstra , "Frank Ch. Eigler" , Ingo Molnar , LKML , systemtap-ml , Hideo AOKI Subject: Re: [RFC][Patch 2/2] markers: example of irq regular kernel markers In-Reply-To: <20080621190132.E835.KOSAKI.MOTOHIRO@jp.fujitsu.com> Message-ID: References: <20080620174529.GB10943@Krystal> <485C064E.5020705@redhat.com> <20080621190132.E835.KOSAKI.MOTOHIRO@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2008-q2/txt/msg00702.txt.bz2 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