From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Vince Weaver <vincent.weaver@maine.edu>,
Paul Mackerras <paulus@samba.org>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH 1/2] perf: return ENOENT instead of ENOTSUPP
Date: Thu, 11 Jun 2015 12:25:01 +0200 [thread overview]
Message-ID: <1434018301.1495.73.camel@twins> (raw)
In-Reply-To: <1434016745-17608-1-git-send-email-brueckner@linux.vnet.ibm.com>
On Thu, 2015-06-11 at 11:59 +0200, Hendrik Brueckner wrote:
> The ENOTSUPP (which actually should be EOPNOTSUPP for user space) does not
> trigger a fallback event selection, for example, by perf record.
> If hardware support for the cycles perf event is available, but the hardware
> does not provide interrupts, returning ENOTSUPP causes perf to end. Returning
> ENOENT causes the perf tool to fallback to a software-based cycle PMU that
> supports interrupts.
>
> The commit 53b25335dd ("perf: Disable sampled events if no PMU interrupt")
> introduced that incompatible change.
That's 3.16
> if (event->pmu->capabilities & PERF_PMU_CAP_NO_INTERRUPT) {
> - err = -ENOTSUPP;
> + err = -ENOENT;
> goto err_alloc;
> }
> }
And now you would be changing an API that's been around for at least 4
releases.
Also, I really think -ENOENT is the wrong return here, you're asking for
things that's not supported, not for something that's not there.
next prev parent reply other threads:[~2015-06-11 10:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-11 9:59 [PATCH 1/2] perf: return ENOENT instead of ENOTSUPP Hendrik Brueckner
2015-06-11 9:59 ` [PATCH 2/2] perf: correct event accounting imbalance on error path Hendrik Brueckner
2015-06-11 10:25 ` Peter Zijlstra [this message]
2015-06-11 13:02 ` [PATCH 1/2] perf: return ENOENT instead of ENOTSUPP Hendrik Brueckner
2015-06-11 13:28 ` Peter Zijlstra
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=1434018301.1495.73.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=acme@kernel.org \
--cc=brueckner@linux.vnet.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paulus@samba.org \
--cc=schwidefsky@de.ibm.com \
--cc=vincent.weaver@maine.edu \
/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.