Messages in this thread | | | Date | Tue, 20 Jul 2010 00:19:39 -0400 | From | Christoph Hellwig <> | 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 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.
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.
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. This is what basically all patches to the kernel do, and what's also suggested in Documentation/SubmittingPatches.
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@linux.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
...
| |