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

[Warner Losh]

On Aug 8, 2013, at 7:33 PM, David O'Brien wrote:

> On Thu, Aug 08, 2013 at 02:58:53PM -0700, Simon Gerraty wrote:
>> If there are bread crumbs to show whether an RNG is present or not in
>> the output from config, it should be feasible to fail the build
>> which as others have noted would be a "good thing"[TM] vs producing a
>> toxic kernel.
> 
> I may have misunderstood what you're saying.  But if not, you're
> not allowing for one using .ko's to have this functionality.
> 
> How do I fail the build if I want to have 'device random' but use
> some external provided RNG thru a kernel module?  The original
> changeset supported that.  Or for what ever reason I want to have
> the choice of RNG left up to which base kernel module I load?

I still don't understand why Yarrow can't be the default, fallback mechanism that gets overridden when a new module is loaded. Rather than arguing this point, perhaps you could work to make that possible? That would allow you to implement things with hardware png, while still providing a sane fallback until such time that those can be loaded,,,

> 'sysctl kern.random.adaptors' showing an empty list does provide
> a bread crumb.  /etc/rc.d/initrandom could certainly check this
> value and complain loudly.

The poison has been drunk at this time, it is too late to back out gracefully.

Warner