From: Michael Ellerman <mpe@ellerman.id.au>
To: Vince Weaver <vincent.weaver@maine.edu>
Cc: Dave Jones <davej@redhat.com>, trinity@vger.kernel.org
Subject: Re: [PATCH 1/2] Add an IGNORE_ENOSYS flag and use it
Date: Wed, 28 May 2014 13:27:54 +1000 [thread overview]
Message-ID: <1401247674.5468.2.camel@concordia> (raw)
In-Reply-To: <alpine.DEB.2.10.1405270057180.1362@vincent-weaver-1.umelst.maine.edu>
On Tue, 2014-05-27 at 01:02 -0400, Vince Weaver wrote:
> On Tue, 27 May 2014, Michael Ellerman wrote:
>
> > On Mon, 2014-05-26 at 20:41 -0400, Dave Jones wrote:
> > > On Mon, May 26, 2014 at 10:32:01PM +1000, Michael Ellerman wrote:
> > > > Some syscalls return ENOSYS depending on their arguments. We don't want
> > > > to stop calling them just because we hit one of those cases. Add a flag
> > > > to specify this behaviour so we don't have to keep special-casing those
> > > > calls in mkcall().
> > >
> > > I was hopeful this list wouldn't grow, but that doesn't seem to be
> > > the case. Begrudgingly, I applied this. It's going to be a lot
> > > cleaner to maintain if people keep doing this.
> >
> > Yeah it's annoying for sure, maybe perf will be the last one, but at least
> > there's a clean way to handle it if not.
>
> As the author of the man page that you probably got the perf ENOSYS info
> from, I have to put out there that perf_event_open() has really
> inconsistent and confusing error return values, and they vary among the
> various architectures.
Actually I didn't read the man page, but thanks for reminding me that it
exists. And yes I am aware of your dislike of the perf interface.
> I'd hope other syscalls do better, but it's really easy to slip in weird
> return values in unexpected places. I somewhat try to follow the
> perf_event ABI and watch for stuff like this (if only to keep the manpage
> up to date) but I missed the ENOSYS commit at the time (especially since
> it's not possible to trigger on x86 where I do most of my testing).
Yeah it's our fault in a way, in that we didn't test that code on powerpc prior
to it going in. But with the pace things move sometimes that happens. It's
annoying but not the end of the world.
cheers
next prev parent reply other threads:[~2014-05-28 3:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-26 12:32 [PATCH 1/2] Add an IGNORE_ENOSYS flag and use it Michael Ellerman
2014-05-26 12:32 ` [PATCH 2/2] Mark perf_event_open() with IGNORE_ENOSYS Michael Ellerman
2014-05-27 0:41 ` [PATCH 1/2] Add an IGNORE_ENOSYS flag and use it Dave Jones
2014-05-27 1:05 ` Michael Ellerman
2014-05-27 5:02 ` Vince Weaver
2014-05-28 3:27 ` Michael Ellerman [this message]
2014-05-28 15:38 ` Vince Weaver
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=1401247674.5468.2.camel@concordia \
--to=mpe@ellerman.id.au \
--cc=davej@redhat.com \
--cc=trinity@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox