linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Andy Lutomirski <luto@amacapital.net>,
	Linux Kernel Developers List <linux-kernel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	linux-crypto@vger.kernel.org
Subject: Re: [PATCH -v5] random: introduce getrandom(2) system call
Date: Thu, 24 Jul 2014 19:24:34 -0400	[thread overview]
Message-ID: <20140724232434.GN6673@thunk.org> (raw)
In-Reply-To: <20140724203019.GA20737@khazad-dum.debian.net>

On Thu, Jul 24, 2014 at 05:30:19PM -0300, Henrique de Moraes Holschuh wrote:
> > I wouldn't add the error to the man page until we actually modify the
> > kernel to add such a restriction.
> 
> By then, it might be too late.  It would be really sad to find ourselves
> forced to return ENOSYS to getrandom(GRND_RANDOM) when we actually wanted to
> return EPERM/EACCES.

I wouldn't worry about.  The reality is that anyone using GRND_RANDOM
has to be checking for error codes anyway, and if they do something
stupid because the system call returns EPERM/EACCESS when they weren't
expecting it, again, they are much more likely to be making many other
fatal mistakes anyway.

In general, all system calls can return errno's other than the ones
documented in the man page.  This is certainly true for open(2), and
read(2) if you are using a network file system such as NFS.  Someone
who assumes that the only errors that they have to handle is the list
in the man page, and assumes that this list is an exhaustive listing
of all possible errors, is going to be in a *world* of hurt.

I don't think it's necessary to add a sentence that other errors can
be returned in the future, and users much check for other errors, but
if you really think people are that stupid that we need to say
something which is true for every single system call in Linux, we can
do that....

						- Ted

  parent reply	other threads:[~2014-07-24 23:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-24 14:31 [PATCH -v5] random: introduce getrandom(2) system call Theodore Ts'o
2014-07-24 15:18 ` Henrique de Moraes Holschuh
2014-07-24 15:21   ` Andy Lutomirski
2014-07-24 19:02     ` Theodore Ts'o
2014-07-24 20:30       ` Henrique de Moraes Holschuh
2014-07-24 20:54         ` Andy Lutomirski
2014-07-24 23:27           ` H. Peter Anvin
2014-07-24 23:24         ` Theodore Ts'o [this message]
2014-07-24 23:27           ` Andy Lutomirski
     [not found]             ` <CALCETrVgKMVnBuzE+bCXaUPRrqhVxwv4AXmJrUJSYws5rZxhJw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-07-25 13:22               ` Theodore Ts'o
     [not found]           ` <20140724232434.GN6673-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2014-07-25 12:46             ` Henrique de Moraes Holschuh
     [not found] ` <1406212287-9855-1-git-send-email-tytso-3s7WtUTddSA@public.gmane.org>
2014-07-30 14:34   ` Rolf Eike Beer

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=20140724232434.GN6673@thunk.org \
    --to=tytso@mit.edu \
    --cc=hmh@hmh.eng.br \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    /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;
as well as URLs for NNTP newsgroup(s).