[PATCH v7] getrandom system call wrapper [BZ #17252]

[Florian Weimer]

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.

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.

Would this work for you?

Thanks,
Florian