5 ms·
> They try not to break userland code, yes, but userland code only relies on things the docs say it can, so... Judging from the odd Torvalds-yelling-at-people
by ben0x539 11y ago
> They try not to break userland code, yes, but userland code only relies on things the docs say it can, so...
Judging from the odd Torvalds-yelling-at-people mail getting linked on HN, it doesn't sound like "it's ok to break userland here because clearly they didn't read the docs" would fly.
- tptacek 11y agoThe proposed change --- unify urandom/random and permanently lose blocking behavior --- can't possibly break userland. There is no way to write a program that depends on /dev/random blocking, because it does so at random.
- JoachimSchipper 10y agoI've seen you post that a few times, so two minor nitpicks. In the mental model in which the /dev/random manpage lives, it makes (some) sense to read /dev/random until you get a short read, then make a userland pool from all the data you've read, "to get as much entropy as possible". That reasoning doesn't actually make sense, of course, but I would be surprised if nobody thought that such a construction would be a good idea. Separately, there's quite a lot of code - and I've written some - that reads a byte from /dev/random at daemon start, specifically to block until the system has built up enough entropy. FreeBSD blocks reads, even from /dev/urandom, until the [EDIT: estimate of how much entropy has ever gone into the pool] gets high enough, which makes some sense; but there needs to be some way to block-until-random.
- tptacek 10y agoFreeBSD blocks until the generator is seeded. I think Linux urandom should do the same thing. But once it's seeded, there is no reason for the generator ever to block again.
- JoachimSchipper 10y agoYes, that's what I meant. Edited for clarity, thanks!
- mioelnir 10y agoOn 11.x random routinely unblocks before the userland is even started, so from an application standpoint random really never blocks.