Date:	Tue, 20 Jul 2010 12:08:05 +0530
From:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <rostedt@...dmis.org>,
	Randy Dunlap <rdunlap@...otime.net>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Naren A Devaiah <naren.devaiah@...ibm.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Mark Wielaard <mjw@...hat.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCHv9 2.6.35-rc4-tip 0/13]  Uprobes Patches:


> I tried this again and it worked.  That is kinda worked becuase I could

Thanks for trying.

> use it to trace things in my running bash instance, but haven't really
> figured out how to trace something useful using the pid based interface.
> The processes I care about really don't run long enough for that.

I am working/(continue to work) on file based probes. But
currently spending some of my time merging the current patchset to
latest tip. Once this patchset gets pushed to tip, I should be able to
speed up the file based probing.

> 
> So thanks for the good work so far, but we'll really need a way to
> define the trace points per-file and have a way to invoke a program
> with tracing that uses it enabled.
> 
> A minor note on perf probe -S output:  This seems to include a lot of
> T.456 or similar labels, which from my recollection are gcc internal
> things.  It would be good to filter those out as they aren't quite
> useful and just fill up the list.

Okay .. will take a look. Offhand I dont know about the T.456
labels, so I will google and see if its possible for us to identify if
its a t.456 label. However if you know how to identify a t456 label
from normal functions, then it would be great.

> 
> 
> And I really need to complain about the per-patch changelogs inside
> the visible commit message again.  I know you disagree, but it's
> a real pain to read through it in git-log when you look for information
> about the patch (which for some of the patches is rather short anyway)
> and all you see is some rather useless patch versioning changelogs.

I am okay with dropping the Changelog or moving the Changelog under the
--- section. However I had retained it because Stephen Rostedt
replied to your post saying he found Changelog to be useful. 

Assuming, he is fine dropping the changelog, I will move the
Changelog to the --- section as suggested by you. 

> This is what basically all patches to the kernel do, and what's also
> suggested in Documentation/SubmittingPatches.

Agree. 

> 
> While talking about changelogs: your patches duplicate the patch
> subject line inside the mail body, leading to rather funny git
> commit messages after a git-am:
> 
> commit c32a1b63db113bb1508dbf01af34d29f6cda747a
> Author: Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
> Date:   Mon Jul 12 16:04:42 2010 +0530
> 
>     perf: show functions in a file without using pid
>         
>     [RFC] perf: show functions in a file without using pid

Okay, I shall drop the Subject from the body of the patch next time I
send the patchset.

--
Thanks and Regards
Srikar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists