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

Andrey Chernov ache at freebsd.org
Thu Aug 8 13:01:06 UTC 2013


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.

-- 
http://ache.vniz.net/
bitcoin:1G6ugdNY6e5jx1GVnAU2ntj2NEfmjKG85r


More information about the freebsd-arch mailing list