Date: Thu, 8 Aug 2013 10:23:52 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org Cc: Arthur Mesh <arthurmesh@gmail.com>, secteam@freebsd.org, Steve Kargl <sgk@troutmask.apl.washington.edu> Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <201308081023.53040.jhb@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 Wednesday, August 07, 2013 4:20:29 pm Peter Wemm wrote: > 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. The counter to this is that in the recent past, any suggestion to add anything to DEFAULTS was met with "that's the wrong way". In actual fact, changes to GENERIC happen quite often, and we often break older kernel configs from older branches (ATA_CAM is no longer in 10 for example). I'm not sure I buy the argument that we can never break kernel configs from older branches. I also think that NO_FOO options aren't the way to go and that we should always create "positive" options, but add them to GENERIC when making a previously standard thing optional. I think adding things to DEFAULTS should be rarely done, if ever. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201308081023.53040.jhb>