Hi Ted, On 11/11/2016 05:05 PM, Theodore Ts'o wrote: > 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. :-) Well, as noted in another reply, I did restore that line, but elaborated a little: [[ Reads from this device do not block (i.e., the CPU is not yielded), but can incur an appreciable delay when requesting large amounts of data. ]] > 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. :-/ Possible confirmation bias? Perhaps the people that *do* read the man page don't bother with debates? > >> .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. Thanks for checking it. 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
