Hello Laurent, On 11/11/2016 11:28 AM, Laurent Georget wrote: > Hello, > > Le 10/11/2016 à 15:20, Michael Kerrisk (man-pages) a écrit : >> Hello all, >> >> While reworking the text of the random(4) page, I found >> what appear to be some inaccuracies. Could I get some feedback >> on the patch below? >> >> Thanks, >> >> Michael >> >> 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. >> >> Signed-off-by: Michael Kerrisk <mtk.manpages@xxxxxxxxx> >> >> diff --git a/man4/random.4 b/man4/random.4 >> index db5d0a2..736cbde 100644 >> --- 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. > > Being non blocking is not incompatible with being interruptible, though. > Non blocking only means that the reading will never explicitly yield the > CPU to wait for data, which is true. This is consistent with the use of > "non blocking" elsewhere in the filesystem, as far as I understand it. Yes, I see. Perhaps we can find a middle ground. I restored the removed line, but elaborated a little: [[ Reads from this device do not block (i.e., the CPU is not yielded), but may incur an appreciable delay when requesting a large amount (megabytes) of data. ]] > But I guess this can be confusing indeed, and that the precision is not > useful in the man page. > >> 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 >> @@ -88,8 +87,11 @@ When calling >> .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, this is a useful precision. > > This patch looks good to me. Thanks. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- 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
