Date: Wed, 7 Aug 2013 13:20:29 -0700 From: Peter Wemm <peter@wemm.org> To: Steve Kargl <sgk@troutmask.apl.washington.edu> Cc: Arthur Mesh <arthurmesh@gmail.com>, secteam@freebsd.org, freebsd-arch@freebsd.org Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <CAGE5yCq%2Bs6kYtVYyxi27RAqPmvpV42nNNykm2%2B2x1EJGCihYXw@mail.gmail.com> In-Reply-To: <20130807192736.GA7099@troutmask.apl.washington.edu> References: <20130807182858.GA79286@dragon.NUXI.org> <20130807192736.GA7099@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Aug 7, 2013 at 12:27 PM, Steve Kargl <sgk@troutmask.apl.washington.edu> wrote: > On Wed, Aug 07, 2013 at 11:28:58AM -0700, David O'Brien wrote: >> >> * Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" >> option. The files sha2.c, hash.c, randomdev_soft.c and yarrow.c >> comprise yarrow. random(4) device doesn't really depend on >> rijndael-*. Yarrow, however, does. >> >> * If the kernel doesn't have any random_adaptor adapters present then >> the creation of /dev/random is postponed until next random_adaptor >> is kldload'ed. > > My kernel config files have included the following 2 lines for > ages: > > makeoptions NO_MODULES > device random > > If I try to build a new kernel under your scheme, will the > build die with an error about a missing option? If the answer > is 'no', then the yarrow adaptor should be opt-out. 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. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. <brueffer> ZFS must be the bacon of file systems. "everything's better with ZFS"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGE5yCq%2Bs6kYtVYyxi27RAqPmvpV42nNNykm2%2B2x1EJGCihYXw>