On Tue, 2016-11-29 at 15:40 +0100, Florian Weimer wrote:
On 11/29/2016 02:56 PM, Torvald Riegel wrote:
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).
Hmph.
Note that I mean that this is my preference specifically in the scenario
of adding some sort of flag to getrandom() and offering only
getrandom().
I was about to propose a new patch, with two functions:
getrandom, as I posted it the last time (an unadorned system call which
is also a cancellation point).
getentropy, a thin wrapper which avoids returning EINTR (to match
OpenBSD and Solaris) and is not a cancellation point. It would return
EIO on short reads, too.
The documentation would have said that getrandom is a lower-level
function for those which need GRND_RANDOM or cancellation, and everyone
else should call getrandom.
I guess one of these should be getentropy (the latter?).
Would this work for you?
Yeah, I guess so. I can't really estimate how obvious it would be for
users to have to consider the pair of these (and thus make a conscious
choice and understand what cancellation means) -- but if we can make
this fairly obvious (eg, through proper documentation) and thus are
likely to prevent users from making a mistake, and we have an
alternative for the non-cancellation use case, then I guess this could
be a meaningful solution.