public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Torvald Riegel <triegel@redhat.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Szabolcs Nagy <szabolcs.nagy@arm.com>,
	Adhemerval Zanella <adhemerval.zanella@linaro.org>,
	nd@arm.com, libc-alpha@sourceware.org
Subject: Re: [PATCH v7] getrandom system call wrapper [BZ #17252]
Date: Tue, 29 Nov 2016 13:56:00 -0000	[thread overview]
Message-ID: <1480427804.14990.24.camel@redhat.com> (raw)
In-Reply-To: <1682bf93-5fbc-80db-1348-e5b8973a59f2@redhat.com>

On Tue, 2016-11-29 at 09:16 +0100, Florian Weimer wrote:
> On 11/18/2016 05:04 PM, Torvald Riegel wrote:
> > On Fri, 2016-11-18 at 16:13 +0100, Florian Weimer wrote:
> >> On 11/18/2016 03:21 PM, Torvald Riegel wrote:
> >>
> >>> As discussed in the thread, there are different opinions about what the
> >>> default should be.  There are reasonable arguments for both options.  In
> >>> such a case, it seems better to make the choice explicit, simply from an
> >>> ease-of-use and interface design perspective.
> >>
> >> Unfortunately, this is not the approach that POSIX has chosen.  But
> >> there is precedent for doing our own thing in this area: the "c" flag
> >> for fopen.  We cannot use the existing flags argument in getrandom for
> >> this purpose because its layout is controlled by the kernel.
> >
> > It seems a separate argument would be better than using up space in the
> > existing flags.  Cancellation is something we add, so we should add to
> > the underlying interface too, instead of messing with it.
> 
> Is this separate argument your personal preference, or are you just 
> trying to find common ground and reconcile different positions?

It's my personal preference.  Which is partially motivated by trying to
find common ground between the different use cases (and not finding
obvious common group, so therefore make the choice explicit).


  reply	other threads:[~2016-11-29 13:56 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-10 21:03 [PATCH] Add getrandom implementation " Florian Weimer
2016-06-10 21:31 ` Joseph Myers
2016-06-10 21:36   ` Joseph Myers
2016-06-10 22:00   ` Paul Eggert
2016-06-10 22:06     ` Joseph Myers
2016-06-11 11:13   ` Florian Weimer
2016-06-11 20:10     ` Paul Eggert
2016-06-10 22:15 ` Roland McGrath
2016-06-10 22:40   ` Joseph Myers
2016-06-10 22:45     ` Roland McGrath
2016-06-23 17:21   ` Florian Weimer
2016-06-25 21:58     ` Paul Eggert
2016-09-02 22:23     ` Roland McGrath
2016-06-27 15:07 ` [PATCH v2] " Florian Weimer
2016-06-30  9:33   ` Rical Jasan
2016-09-08  9:53     ` Florian Weimer
2016-09-08 10:13       ` Andreas Schwab
2016-09-08 10:28         ` Florian Weimer
2016-09-08 11:58       ` Rical Jasan
2016-09-08 12:36         ` Florian Weimer
2016-06-30 12:03   ` Zack Weinberg
2016-07-13 13:10     ` Nikos Mavrogiannopoulos
2016-11-14 17:45 ` [PATCH v7] getrandom system call wrapper " Florian Weimer
2016-11-14 18:29   ` Zack Weinberg
2016-11-15 20:57     ` Richard Henderson
2016-11-16 15:11     ` Florian Weimer
2016-11-16 15:20       ` Zack Weinberg
2016-11-16 15:52         ` Florian Weimer
2016-11-16 16:41           ` Zack Weinberg
2016-11-17 13:02             ` Florian Weimer
2016-11-17 13:46               ` Zack Weinberg
2016-11-17 13:50                 ` Florian Weimer
2016-11-17 13:56                   ` Zack Weinberg
2016-11-17 15:24                     ` Florian Weimer
2016-11-17 17:16                       ` Zack Weinberg
2016-11-18 10:27                         ` Szabolcs Nagy
2016-11-18 15:46                           ` Torvald Riegel
2016-11-18 18:50                           ` Zack Weinberg
2016-11-21 16:57                             ` Torvald Riegel
2016-11-21 17:12                               ` Zack Weinberg
2016-11-21 17:30                                 ` Torvald Riegel
2016-11-21 17:34                                   ` Florian Weimer
2016-11-29  8:24                             ` Florian Weimer
2016-11-16 18:02           ` Torvald Riegel
2016-11-16 19:53             ` Adhemerval Zanella
2016-11-17 12:52               ` Torvald Riegel
2016-11-18  8:28                 ` Szabolcs Nagy
2016-11-18 14:21                   ` Torvald Riegel
2016-11-18 15:13                     ` Florian Weimer
2016-11-18 16:04                       ` Torvald Riegel
2016-11-29  8:16                         ` Florian Weimer
2016-11-29 13:56                           ` Torvald Riegel [this message]
2016-11-29 14:40                             ` Florian Weimer
2016-11-29 15:23                               ` Torvald Riegel
2016-11-29 15:32                                 ` Florian Weimer
2016-11-29 15:54                                   ` Zack Weinberg
2016-11-29 17:53                                     ` Paul Eggert
2016-11-29 18:11                                       ` Florian Weimer
2016-11-29 19:37                                         ` Paul Eggert
2016-11-30  6:09                                           ` Florian Weimer
2016-11-17  6:21   ` Mike Frysinger
2016-11-18 13:21     ` Florian Weimer

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=1480427804.14990.24.camel@redhat.com \
    --to=triegel@redhat.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=nd@arm.com \
    --cc=szabolcs.nagy@arm.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).