public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nikolaus Rath <Nikolaus@rath.org>
To: Mike Marshall <hubcap@omnibond.com>
Cc: Miklos Szeredi <mszeredi@redhat.com>,
	Andrew Gallagher <andrewjcg@fb.com>,
	lkml <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT
Date: Tue, 15 Nov 2016 07:50:11 -0800	[thread overview]
Message-ID: <87d1hwagjw.fsf@thinkpad.rath.org> (raw)
In-Reply-To: <CAOg9mSQbJ07j1EewZysWfFV0cR=Mo5JxvjuFJ99PdSTTMDy3_A@mail.gmail.com> (Mike Marshall's message of "Fri, 11 Nov 2016 12:53:39 -0500")

On Nov 11 2016, Mike Marshall <hubcap@omnibond.com> wrote:
> There was a memorable place in the Orangefs code where
> the original programmer did that (pick something appropriate
> from errno.h) and put in a comment about how it was a more
> reasonable return code...
>
> When Al Viro saw it, he said it was:
>
> ... stupid.  Expected error value is not EOPNOTSUPP; pardon the bluntness,
> but your idea of what would be less misleading doesn't matter - what matters
> is what the _callers_ of link(2), mknod(2), etc. are expecting.  Which is to
> say, what does the userland code expect to get.  It's outright promised in
> POSIX, actually.


I still have to see an application that, upon receiving an error from
e.g. link(2), has special handlers for each of the 24 possible 24 error
codes. All code that I have seen (and written) check for a few specific
errors, and punts everything else to the user via strerror(). In this
case, returning more specific error codes gives the user better
information and doesn't violate any expectations of the application.

Best,
-Nikolaus
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

  reply	other threads:[~2016-11-15 15:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-10 22:31 commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT Nikolaus Rath
2016-11-10 23:12 ` Miklos Szeredi
2016-11-11  4:57   ` Nikolaus Rath
2016-11-11  8:43     ` Miklos Szeredi
2016-11-11 16:28       ` Nikolaus Rath
2016-11-11 16:53         ` Mike Marshall
2016-11-11 17:27           ` Nikolaus Rath
2016-11-11 17:53             ` Mike Marshall
2016-11-15 15:50               ` Nikolaus Rath [this message]
2016-11-15 13:33             ` Miklos Szeredi
2016-11-15 15:53               ` Nikolaus Rath

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=87d1hwagjw.fsf@thinkpad.rath.org \
    --to=nikolaus@rath.org \
    --cc=andrewjcg@fb.com \
    --cc=hubcap@omnibond.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mszeredi@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox