From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752188AbbIOChF (ORCPT ); Mon, 14 Sep 2015 22:37:05 -0400 Received: from casper.infradead.org ([85.118.1.10]:41066 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751626AbbIOChD (ORCPT ); Mon, 14 Sep 2015 22:37:03 -0400 Date: Mon, 14 Sep 2015 23:35:57 -0300 From: Arnaldo Carvalho de Melo To: =?iso-8859-1?Q?Rapha=EBl?= Beamonte Cc: Jiri Olsa , Jiri Olsa , lkml , David Ahern , Ingo Molnar , Namhyung Kim , Peter Zijlstra , Matt Fleming Subject: Re: [PATCH 4/5] perf tools: Propagate error info from tp_format Message-ID: <20150915023557.GB11551@kernel.org> References: <1441615087-13886-1-git-send-email-jolsa@kernel.org> <1441615087-13886-5-git-send-email-jolsa@kernel.org> <20150909205813.GV3475@kernel.org> <20150910082452.GC19014@krava.brq.redhat.com> <20150914205303.GF5250@kernel.org> <20150914213627.GL5250@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 : > > 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 : > >> > +++ 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); > >> > }