From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
To: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>,
Ramkumar Ramachandra <artagnon@gmail.com>,
LKML <linux-kernel@vger.kernel.org>, Jiri Olsa <jolsa@redhat.com>
Subject: Re: [PATCH] perf tool: report user-friendly error from timechart
Date: Thu, 3 Oct 2013 14:08:02 -0300 [thread overview]
Message-ID: <20131003170802.GB2436@ghostprotocols.net> (raw)
In-Reply-To: <524D7296.3090407@gmail.com>
Em Thu, Oct 03, 2013 at 07:35:18AM -0600, David Ahern escreveu:
> On 10/3/13 6:38 AM, Ingo Molnar wrote:
> >
> >* Ramkumar Ramachandra <artagnon@gmail.com> wrote:
> >
> >>+ /* Perform a quick sanity check */
> >>+ if (!is_valid_tracepoint("power:cpu_frequency")) {
> >>+ fprintf(stderr, "Error:\tNo permissions to read $debugfs/tracing/events/power/cpu_frequency\n");
> >>+ fprintf(stderr, "Hint:\tChange the permissions of debugfs: /sys/kernel/debug\n");
> >>+ fprintf(stderr, "\tThe directory will be present if your kernel was compiled with debugfs support.\n");
> >
> >Is missing permissions the only way how is_valid_tracepoint() can fail?
> >
> >What if debugfs has the right permissions but CONFIG_TRACEPOINTS is
> >disabled in the kernel?
>
> There are a number of reasons that function can fail. The complete
> solution is to plumb various error numbers and on failure request a
> string for that failure. Take a look at util/target.[ch] as an
> example.
>
> The comment applies to the perf-trace patch as well, but it gets
> more complicated to handle the error paths from perf_evsel__newtp
> when they dip into the tracepoint code
See the patch I posted, in that case we can use the old errno way, i.e.
do nothing and just look at it in the perf_evsel__newtp/
perf_evlist__add_newtp callers.
And is_valid_tracepoint() is a too big hammer, it traverses the whole
directory looking for a match instead of plain build the path and do an
access, its one of those things I need to ditch at some point. So far I
just try to do a perf_evlist__add_newtp and if it fails, look at errno.
- Arnaldo
next prev parent reply other threads:[~2013-10-03 17:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-03 9:05 [PATCH] perf tool: report user-friendly error from timechart Ramkumar Ramachandra
2013-10-03 12:38 ` Ingo Molnar
2013-10-03 12:43 ` Ramkumar Ramachandra
2013-10-03 13:09 ` Ingo Molnar
2013-10-03 13:35 ` David Ahern
2013-10-03 17:08 ` Arnaldo Carvalho de Melo [this message]
2013-10-03 17:22 ` David Ahern
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=20131003170802.GB2436@ghostprotocols.net \
--to=acme@ghostprotocols.net \
--cc=artagnon@gmail.com \
--cc=dsahern@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
/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.