Date: Thu, 08 Aug 2013 17:01:01 +0400 From: Andrey Chernov <ache@freebsd.org> To: Peter Wemm <peter@wemm.org> Cc: Arthur Mesh <arthurmesh@gmail.com>, secteam@freebsd.org, Steve Kargl <sgk@troutmask.apl.washington.edu>, freebsd-arch@freebsd.org Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <5203968D.7060508@freebsd.org> In-Reply-To: <CAGE5yCq%2Bs6kYtVYyxi27RAqPmvpV42nNNykm2%2B2x1EJGCihYXw@mail.gmail.com> References: <20130807182858.GA79286@dragon.NUXI.org> <20130807192736.GA7099@troutmask.apl.washington.edu> <CAGE5yCq%2Bs6kYtVYyxi27RAqPmvpV42nNNykm2%2B2x1EJGCihYXw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5203968D.7060508>