> "totally block"? > > For a blocking fd, read(2) has always blocked until some data is > available. There has never been a guarantee, for any driver, that > a read(2) will return the full amount of bytes requested. Hmm.. Some came to mind : Making /dev/random block if the amount requirements aren't met makes sense to me. If I request x bytes of random stuff, and get less, I probably reread /dev/random. If it's entropy pool is exhausted it makes sense to be to block. Just some mind spin. > There is no need to document this... man read(2) ;-) > > Jeff Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
- Re: /dev/random probs in 2.4test(12-pre3) Andrew Morton
- Re: /dev/random probs in 2.4test(12-pre3) Igmar Palsenberg
- Re: /dev/random probs in 2.4test(12-pre3) H. Peter Anvin
- Re: /dev/random probs in 2.4test(12-pre3) Albert D. Cahalan
- Re: /dev/random probs in 2.4test(12-pre3) Igmar Palsenberg
- Re: /dev/random probs in 2.4test(12-pre3) Jeff Garzik
- Re: /dev/random probs in 2.4test(12-pre3) Igmar Palsenberg
- Re: /dev/random probs in 2.4test(12-pre3) David Ford
- Re: /dev/random probs in 2.4test(12-pre3) H. Peter Anvin
- Re: /dev/random probs in 2.4test(12-pre3) Kai Henningsen
- Re: /dev/random probs in 2.4test(12-pre3) Igmar Palsenberg
- Re: /dev/random probs in 2.4test(12-pre3) David Ford
- Re: /dev/random probs in 2.4test(12-pre3) Igmar Palsenberg
- Re: /dev/random probs in 2.4test(12-pre3) H. Peter Anvin
- Re: /dev/random probs in 2.4test(12-pre3) H. Peter Anvin