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. 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. Cheers, Laurent
Attachment:
signature.asc
Description: OpenPGP digital signature
