From: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>
To: "Raphaël Beamonte" <raphael.beamonte@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>, Jiri Olsa <jolsa@kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
David Ahern <dsahern@gmail.com>, Ingo Molnar <mingo@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Matt Fleming <matt@codeblueprint.co.uk>
Subject: Re: [PATCH 4/5] perf tools: Propagate error info from tp_format
Date: Mon, 14 Sep 2015 23:35:57 -0300 [thread overview]
Message-ID: <20150915023557.GB11551@kernel.org> (raw)
In-Reply-To: <CAE_Gge1O=789+n4xWad1pMBgcv=e4MEiSdvb=W=k55QN33eN6A@mail.gmail.com>
Em Mon, Sep 14, 2015 at 06:05:38PM -0400, Raphaël Beamonte escreveu:
> 2015-09-14 17:36 GMT-04:00 Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>:
> > Em Mon, Sep 14, 2015 at 04:59:41PM -0400, Raphaël Beamonte escreveu:
> >> 2015-09-14 16:53 GMT-04:00 Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>:
> >> > +++ b/tools/perf/util/evsel.c
> >> > @@ -234,7 +234,9 @@ struct perf_evsel *perf_evsel__newtp_idx(const char *sys, const char *name, int
> >> > struct perf_evsel *evsel = zalloc(perf_evsel__object.size);
> >> > int err = -ENOMEM;
> >> >
> >> > - if (evsel != NULL) {
> >> > + if (evsel == NULL) {
> >> > + goto out_err;
> >> > + } else {
> >>
> >> Is the else really necessary after a goto?
> >
> > Not really, we can remove it and all would be equivalent (the code
> > with/without should be the same), its just that I wanted to avoid
> > touching the identation to reduce patch size and since we need o open a
> > brace to declare that attr variable...
>
> Ok. Though, given the content of that function, we could probably
> declare attr in the first lines of the function and assign it its
> value after the if. But I understand the patch size argument! :o)
Yeah, in other times I would have cleaned it all up, having that else is
ugly, but review time is more expensive, I think, so we need to reduce
its cost.
Cleaning it up makes it easier to read, but we get the info about when
that particular code was written buried a bit below the reindentation
cset.
Would be nice to have a 'git blame' that would just unwind things like
that :-)
> On another subject, but on the same lines, shouldn't we use if
> (!evsel) instead of if (evsel == NULL)? (kernel code style if I'm not
> mistaken) Or is there something that prevents from using it here?
I'd say both are ok. (evsel) is shorter than (evsel != NULL), but the
later is more expressive, at a glance you know it is a pointer, etc.
- Arnaldo
> >> > struct perf_event_attr attr = {
> >> > .type = PERF_TYPE_TRACEPOINT,
> >> > .sample_type = (PERF_SAMPLE_RAW | PERF_SAMPLE_TIME |
> >> > @@ -261,6 +263,7 @@ struct perf_evsel *perf_evsel__newtp_idx(const char *sys, const char *name, int
> >> > out_free:
> >> > zfree(&evsel->name);
> >> > free(evsel);
> >> > +out_err:
> >> > return ERR_PTR(err);
> >> > }
> >> >
> >> > diff --git a/tools/perf/util/trace-event.c b/tools/perf/util/trace-event.c
> >> > index 8e3a60e3e15f..802bb868d446 100644
> >> > --- a/tools/perf/util/trace-event.c
> >> > +++ b/tools/perf/util/trace-event.c
> >> > @@ -100,7 +100,7 @@ struct event_format*
> >> > trace_event__tp_format(const char *sys, const char *name)
> >> > {
> >> > if (!tevent_initialized && trace_event__init2())
> >> > - return NULL;
> >> > + return ERR_PTR(-ENOMEM);
> >> >
> >> > return tp_format(sys, name);
> >> > }
next prev parent reply other threads:[~2015-09-15 2:37 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-07 8:38 [PATCHv2 0/5] perf tools: Enhance parsing events tracepoint error output Jiri Olsa
2015-09-07 8:38 ` [PATCH 1/5] tools: Add err.h with ERR_PTR PTR_ERR interface Jiri Olsa
2015-09-08 20:22 ` Raphaël Beamonte
2015-09-08 20:24 ` Raphaël Beamonte
2015-09-08 21:06 ` Arnaldo Carvalho de Melo
2015-09-08 21:28 ` Raphaël Beamonte
2015-09-08 21:29 ` Raphaël Beamonte
2015-09-16 7:28 ` [tip:perf/core] " tip-bot for Jiri Olsa
2015-09-21 23:41 ` Vinson Lee
2015-09-29 6:35 ` Vinson Lee
2015-09-29 7:14 ` Jiri Olsa
2015-09-29 7:20 ` Jiri Olsa
2015-09-29 7:52 ` He Kuang
2015-09-29 7:57 ` Jiri Olsa
2015-09-29 8:15 ` He Kuang
2015-09-29 10:41 ` Jiri Olsa
2015-09-29 14:52 ` Arnaldo Carvalho de Melo
2015-09-29 15:05 ` [PATCH] perf tool: Fix shadowed declaration in parse-events.c Jiri Olsa
2015-10-01 7:10 ` [tip:perf/core] perf tools: " tip-bot for Jiri Olsa
2015-09-07 8:38 ` [PATCH 2/5] perf tools: Add tools/include into tags directories Jiri Olsa
2015-09-15 7:02 ` [tip:perf/core] perf tools: Add tools/ include " tip-bot for Jiri Olsa
2015-09-07 8:38 ` [PATCH 3/5] perf tools: Propagate error info for the tracepoint parsing Jiri Olsa
2015-09-08 21:42 ` Raphaël Beamonte
2015-09-09 7:50 ` Jiri Olsa
2015-09-12 10:54 ` Matt Fleming
2015-09-16 7:29 ` [tip:perf/core] " tip-bot for Jiri Olsa
2015-09-07 8:38 ` [PATCH 4/5] perf tools: Propagate error info from tp_format Jiri Olsa
2015-09-09 20:58 ` Arnaldo Carvalho de Melo
2015-09-10 8:24 ` Jiri Olsa
2015-09-10 14:16 ` Arnaldo Carvalho de Melo
2015-09-14 20:53 ` Arnaldo Carvalho de Melo
2015-09-14 20:59 ` Raphaël Beamonte
2015-09-14 21:36 ` Arnaldo Carvalho de Melo
2015-09-14 22:05 ` Raphaël Beamonte
2015-09-15 2:35 ` Arnaldo Carvalho de Melo [this message]
2015-09-14 21:02 ` Arnaldo Carvalho de Melo
2015-09-16 7:29 ` [tip:perf/core] perf evsel: " tip-bot for Jiri Olsa
2015-09-07 8:38 ` [PATCH 5/5] perf tools: Enhance parsing events tracepoint error output Jiri Olsa
2015-09-10 7:00 ` Namhyung Kim
2015-09-10 8:05 ` Jiri Olsa
2015-09-11 16:09 ` Namhyung Kim
2015-09-11 16:16 ` Jiri Olsa
2015-09-11 17:50 ` Raphaël Beamonte
2015-09-11 18:55 ` Arnaldo Carvalho de Melo
2015-09-11 19:56 ` Raphaël Beamonte
2015-09-11 20:22 ` Arnaldo Carvalho de Melo
2015-09-11 22:01 ` Raphaël Beamonte
2015-09-14 20:59 ` Arnaldo Carvalho de Melo
2015-09-16 7:29 ` [tip:perf/core] " tip-bot for Jiri Olsa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150915023557.GB11551@kernel.org \
--to=arnaldo.melo@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=dsahern@gmail.com \
--cc=jolsa@kernel.org \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=raphael.beamonte@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.