random(4) plugin infrastructure for mulitple RNG in a modular fashion

[Warner Losh]

On Aug 8, 2013, at 7:01 AM, Andrey Chernov wrote:

> On 08.08.2013 0:20, Peter Wemm wrote:
>> That's the main point here.
>> 
>> If I'm running on a working system, I have a reasonable expectation
>> that the kernel config I was using yesterday will work sufficiently
>> tomorrow that I won't get hosed by doing a 'svn update && make
>> buildkernel && make installkernel'.
>> 
>> If that's not the case and there is a required change in order to not
>> hose your system then POLA dictates that not making the required
>> changes causes a build failure.
>> 
>> There's more leeway on head than a stable branch, but remember that
>> when people upgrade from 9.x to 10.x they tend to take their 9.x
>> kernel configs and make whatever changes are needed to get it to
>> build.  The 9-stable -> 10-release config path needs to catch fatal
>> errors like this at build time.
>> 
>> Patching GENERIC isn't a complete solution.  It doesn't solve the
>> 'yesterday it worked, today it's a brick' problem.
> 
> Many years ago I already suggest to de-modularize random (making it not
> optional), with fallback to yarrow if hardware RNGs can't be probed or
> not configured.

I think that the 'fallback to yarrow' is necessary here.

Warner

P.S. Where 'yarrow' can easily be read as 'the best software RNG we've implemented' should that change to something better in the future.