On Thu, Nov 10, 2016 at 03:20:59PM +0100, Michael Kerrisk (man-pages) wrote:
> random.4: Improve discussion or urandom, blocking reads, and signals
>
> The text currently states that O_NONBLOCK has no effect for
> /dev/urandom, which is true. It also says that reads from
> /dev/urandom are nonblocking. This is at the least confusing.
> If one attempts large reads (say 10MB) from /dev/urandom
> there is an appreciable delay, and interruption by a signal
> handler will result in a short read. Amend the text to
> reflect this.
Nonblocking has a very clear and definied meaning in kernel
programming. So it's technically a true statement. As far as whether
it is confusing, I wonder if there are any other statements we discuss
what "non-blocking" means where we might want change things.
as far as deleting this line:
> --- a/man4/random.4
> +++ b/man4/random.4
> @@ -46,7 +46,6 @@ When read, the
> .I /dev/urandom
> device returns random bytes using a pseudorandom
> number generator seeded from the entropy pool.
> -Reads from this device are nonblocking.
> When read during early boot time, this device may return
> data prior to the entropy pool being initialized.
> If this is of concern in your application, use
Meh. I don't really care one way or another. We have a *huge* amount
of detail about the internal implementation of /dev/urandom, so a
novice programmer who doesn't understand the formal meaning of what it
means for an OS system call to block is likely going to be confused by
other things anyway.
There's sort of a larger philosophical question of how much detail to
include, and how much tutorial instruction to include. For example, we could say:
The O_NONBLOCK flag has no effect when opening /dev/urandom or if
set by fcntl(2), since all reads and writes are non-blocking ---
that is, the process will not lose control of the CPU and some
other process will not be scheduled to run during the read or
write system call.
*However*, if the user program requests a large number of bytes
(which is an abuse of the interface, and if a user program does
this the use program is bad and should feel bad, and we reserve
the right to artifically cap the number of bytes returned by a
read to /dev/urandom in the future), the kernel may spend a long
time doing precisely what the user program requested, and so the
system call may not return for a long time.
... but some might argue that's probably too much information. :-)
OTOH, given how much other exhaustive detail is in the man page today,
perhaps it's OK. I dunno. Sorry, it's hard for me to get too excited
one way or another, especially since I continuously get questions and
see debates where it's obvious people aren't reading the man page as
it exists today, so I sometimes get a little cynical about too much
bike-sheddding on man pages. :-/
> .BR read (2)
> for the device
> .IR /dev/urandom ,
> -signals will not be handled until after the requested random bytes
> -have been generated.
> +reads of up to 256 bytes will return as many bytes as are requested
> +and will not be interrupted by a signal handler.
> +Reads with a buffer over this limit may return less than the
> +requested number of bytes or fail with the error
> +.BR EINTR .
>
Yes, that's a good change to make.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
