Re: [PATCH 01/29] perf probe: Try to use symbol table if searching debug info failed

[Arnaldo Carvalho de Melo <acme@redhat.com>]

Em Fri, Aug 21, 2015 at 10:09:02AM +0000, Wang Nan escreveu:
> Although libdw returns an error (Failed to get call frame),
> perf tries symbol table and finally gets correct address.

So, what my script does when processing from the e-mail messages is to
add a Cc: line for each of the e-mail addresses found, that way, in the
git history, we will know who got notifications about the patch.

There is also the Link tag, that it forms using the Message-ID, i.e.:

Link: http://lkml.kernel.org/r/<MESSAGE-ID>

Which I put right before my own "Signed-off-by: Arnaldo" line.

So:

Reported-by: Name <foo@bar.baz>
Signed-off-by: Original Author <e@mail.bla>
Reviewed-by: Name <foo@bar.baz>
Acked-by: Name <foo@bar.baz>
Tested-by: Bla <foo@bar.baz>
Link: http://lkml.kernel.org/r/<MESSAGE-ID>
Signed-off-by: You <you@your.company>

I've been avoiding having the same person in multiple tags, i.e. if
someone reviewed, tested, acked, then no need to have it on the Cc:
list, if someone tested and acked, the Tested-by: is enough, implies an
Acked-by.

My script has a database of e-mail addresses and expands it to have the
names and addresses, i.e.: "Arnaldo Carvalho de Melo <acme@redhat.com>"
instead of just acme@redhat.com, etc.

If someone reacts to your patch and acks it, you should try to add the
relevant tag to your patch, possibly doing a 'rebase -i
patch-just-before, reword it, etc" before I process it, doing so will
reduce the work I have to do to process your patches.

Now ideally this would all happen before you put it somewhere public so
that we don't disrupt git trees cloned from ours, but I'm leaving that
to my upstreamers (Ingo and Linus), which I should refrain from as I go
on pulling from other people more often, which I really want, its all
just a matter of us all agreeing to some common ground on how to format
those patches that doesn't requires me being the one doing the patch
editing, etc, which adds up as a burden, preventing me from doing more
interesting work :)

This set of rules evolved over time as I went by pushing patches to
Ingo, it would be good if you followed it so that I could straight away
pull from your tree.

Anyway, thanks for trying to be taking the steps in that direction, I
will now go back to processing the Intel PT patches so that I can get
back to eBPF.

- Arnaldo
 
> Signed-off-by: Wang Nan <wangnan0@huawei.com>
> ---
>  tools/perf/util/probe-event.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index fe4941a..f07374b 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -705,9 +705,10 @@ static int try_to_find_probe_trace_events(struct perf_probe_event *pev,
>  	}
>  	/* Error path : ntevs < 0 */
>  	pr_debug("An error occurred in debuginfo analysis (%d).\n", ntevs);
> -	if (ntevs == -EBADF) {
> -		pr_warning("Warning: No dwarf info found in the vmlinux - "
> -			"please rebuild kernel with CONFIG_DEBUG_INFO=y.\n");
> +	if (ntevs < 0) {
> +		if (ntevs == -EBADF)
> +			pr_warning("Warning: No dwarf info found in the vmlinux - "
> +				"please rebuild kernel with CONFIG_DEBUG_INFO=y.\n");
>  		if (!need_dwarf) {
>  			pr_debug("Trying to use symbols.\n");
>  			return 0;
> -- 
> 2.1.0