> A little backstory. I started the prandom_32 stuff long ago when I wanted > a better (longer period) PRNG for use in netem. Took the existing code from > older version of GNU scientific library (pre GPLv3). If there is something > faster with better properties go for it. But the whole point of prandom_32 > is that it doesn't have to be crypto quality.
Than you for the encouragement! The lfsr113 generator is really a perfectly respectable generator. There's nothing about it that "needs fixing"; it's just possible to do slighty better. When I can get better statistics, longer period (for the same state size), faster *and* smaller code size, it seems worth looking into. And yes, I understand "pseudorandom" very well. From a documentation patch for drivers/char/random.c I also posted recenty: + * + * prandom_u32() + * ------------- + * + * For even weaker applications, see the pseudorandom generator + * prandom_u32(), prandom_max(), and prandom_bytes(). If the random + * numbers aren't security-critical at all, these are *far* cheaper. + * Useful for self-tests, random error simulation, randomized backoffs, + * and any other application where you trust that nobody is trying to + * maliciously mess with you by guessing the "random" numbers.
