getrandom.2: Rework discussion of blocking section on interuption by signals

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2015-01-29 13:13:32 +01:00
parent 8f891eb06d
commit 3426471b46
1 changed files with 16 additions and 9 deletions

View File

@ -155,7 +155,7 @@ would have blocked if the
flag was not set.
.TP
.B EINTR
While blocked waiting for entropy, the call was interrupted by a signal
The call was interrupted by a signal
handler; see the description of how interrupted
.BR read (2)
calls on "slow" devices are handled with and without the
@ -190,22 +190,29 @@ When a sufficient number of random bits has been collected, the
entropy pool is considered to be initialized.
This state is normally reached early in the system bootstrap phase.
.SS Interruption by a signal handler
A call to
.BR getrandom ()
can block only when called without the
.B GRND_NONBLOCK
flag.
When reading from
.I /dev/urandom
.RB ( GRND_RANDOM
is not set),
blocking can occur if the entropy pool has not been initialized yet
or if the requested number of bytes is large.
.BR getrandom ()
will block until the entropy pool has been initialized
(unless the
.BR GRND_NONBLOCK
flag was specified).
If a request is made to read a large number (more than 256) of bytes,
.BR getrandom ()
will block until those bytes have been generated and transferred
from kernel memory to
.IR buf .
When reading from
.I /dev/random
.RB ( GRND_RANDOM
is set),
blocking occurs if not enough random bytes are available.
.BR getrandom ()
will block until some random bytes become available
(unless the
.BR GRND_NONBLOCK
flag was specified).
The behavior when a call to
.BR getrandom ()