All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: Matt Fleming <matt@codeblueprint.co.uk>
Cc: "Raphaël Beamonte" <raphael.beamonte@gmail.com>,
	"Arnaldo Carvalho de Melo" <acme@kernel.org>,
	"Peter Zijlstra" <a.p.zijlstra@chello.nl>,
	"Ingo Molnar" <mingo@redhat.com>, "Jiri Olsa" <jolsa@kernel.org>,
	"Adrian Hunter" <adrian.hunter@intel.com>,
	"Yunlong Song" <yunlong.song@huawei.com>,
	"Matt Fleming" <matt.fleming@intel.com>,
	"Kan Liang" <kan.liang@intel.com>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Namhyung Kim" <namhyung@kernel.org>,
	"Hemant Kumar" <hemant@linux.vnet.ibm.com>,
	"Masami Hiramatsu" <masami.hiramatsu.pt@hitachi.com>,
	"Wang Nan" <wangnan0@huawei.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] perf: fix confusing messages when not able to read trace events files
Date: Mon, 24 Aug 2015 22:51:55 +0200	[thread overview]
Message-ID: <20150824205155.GH3699@krava.redhat.com> (raw)
In-Reply-To: <20150820135201.GB2567@codeblueprint.co.uk>

On Thu, Aug 20, 2015 at 02:52:01PM +0100, Matt Fleming wrote:

SNIP

> > The err variable doesn't go down to the add_tracepoint_multi_event()
> > call. It actually stops in parse_events_parse() where
> > parse_events_add_tracepoint is being called using only the idx part of
> > data (util/parse-events.y:389). I think it would be possible to pass
> > the whole data variable (struct parse_events_evlist) down those
> > variables to still have access to &err, but it would imply quite a lot
> > of changes in there. I'm up to it though, if it seems that's the right
> > thing to do! What is your take on
> 
> You bring up a good point. Perf would benefit greatly from easy access
> to a struct parse_events_error variable, so that it isn't required to
> pass it as an argument to every function.
> 
> Now, I know that generally global variables are frowned upon but I
> think an exception can be made for error handling, because, assuming
> errors are fatal (and if they're not they're called warnings), you
> should never have multiple things writing to it at the same time, and
> you should only ever execute error paths once you've written to it.
> 
> And if you really, really don't like naked accesses to global
> variables you can always use a wrapper function.
> 
> With global access to error data it becomes trivial to improve the
> error handling of other functions in a piecemeal way, without
> requiring changes to every function in the callstack. No one likes
> reviewing large patches ;-)
> 
> I would suggest setting up a global struct parse_events_error object,
> and making changes to parse_events_print_error() to handle non-parse
> related errors, such as ENOMEM, ENOENT, etc, etc.

hum, I haven't digested all of this thread yet, but I happened
to actually work on this recently - the tracepoint parsing
error propagation ... I did some initial patchset not ready
to be posted but working, please check it in:
  https://git.kernel.org/cgit/linux/kernel/git/jolsa/perf.git/log/?h=perf/tp_5

tracefs and debugfs just give location for accessing tracepoint,
the tracing_events_path is currently initialized to one of them

we could somehow prettyfy it, like unify all the related
interface to make it clear, like the debugfs__strerror_open
shouldn't be 'debugfs' specific and take tracefs into account
as in my patchset

jirka

      reply	other threads:[~2015-08-24 20:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-17  1:39 [PATCH] perf: bugzilla 100781 Raphaël Beamonte
2015-08-17  1:39 ` [PATCH] perf: fix confusing messages when not able to read trace events files Raphaël Beamonte
2015-08-18 11:43   ` Matt Fleming
2015-08-18 17:45     ` Raphaël Beamonte
2015-08-20 13:52       ` Matt Fleming
2015-08-24 20:51         ` Jiri Olsa [this message]

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=20150824205155.GH3699@krava.redhat.com \
    --to=jolsa@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=hemant@linux.vnet.ibm.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=matt.fleming@intel.com \
    --cc=matt@codeblueprint.co.uk \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=raphael.beamonte@gmail.com \
    --cc=rostedt@goodmis.org \
    --cc=wangnan0@huawei.com \
    --cc=yunlong.song@huawei.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.