From: David Ahern <dsahern@gmail.com>
To: Ingo Molnar <mingo@kernel.org>,
Ramkumar Ramachandra <artagnon@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>, Jiri Olsa <jolsa@redhat.com>,
Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Subject: Re: [PATCH] perf tool: report user-friendly error from timechart
Date: Thu, 03 Oct 2013 07:35:18 -0600 [thread overview]
Message-ID: <524D7296.3090407@gmail.com> (raw)
In-Reply-To: <20131003123820.GA12004@gmail.com>
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
David
next prev parent reply other threads:[~2013-10-03 13:35 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 [this message]
2013-10-03 17:08 ` Arnaldo Carvalho de Melo
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=524D7296.3090407@gmail.com \
--to=dsahern@gmail.com \
--cc=acme@ghostprotocols.net \
--cc=artagnon@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.