I think smb covered this  but:

In message <20020529090027.GA13251@rek.tjls.com>, Thor Lancelot Simon writes:
>When you say "there can be code that depends on its predictability" do
>you mean that you've found some code that depends on random() being a
>linear congruential generator?  Ouch!

"Yes, Virginia, there *are* people who embed their monte-carlo
simulations inside the NetBSD kernel!"  My research needed a fast,
reproducible prng, to inject known errors into a TCP stream, to verify
that packet-capture tools were indeed catching those errors.

If random() is a wrapper for a function which, like arc4random(),
rekeys at hard-to-predict times, it cannot be used for such purposes.
(In the end I whacked up something statistically unacceptable but even
faster than random() , but thats another story).

what i see goes beyond consensus to near-unanimity: for the NetBSD
kernel, arc4random() is simply not an appropriate API. Merging with
Jason's list, and Thor's observation about standards, I get:

       1. random(), which can be used for reproducing results.

       2. fast-and-pretty-good generator for things which don't need
         reproducibilility, dno't need  cryptographically strong random
	 numbers, just "pretty good" ones.
	  Example: syn-cache secrets

       3. cryptographically strong generator for cases where you need it,
	 such as CBC IVs.

       4. FIPS-140/ X.whatever compliant (rules out Yarrow)

The API should not use names like arc4random(), since we may wish to
change the underlying algorithms without notice. If we are serious
about crypto certification, the API may need a hook to force calls to
#2 and #3 to acutally invoke #4.  (This could plausibly be a
config-time option rather than runtime.)

It should be straightforward to rework the KAME code to use sucn an
API.  In the simplest case, map them all onto arc4random() or
whatever the best-fit is in Freebsd/OpenBSD.