Re: [PATCHv9 2.6.35-rc4-tip 0/13] Uprobes Patches:

[Christoph Hellwig <hch@infradead.org>]

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

    ...