From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 14:48:03 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A4F147F1; Thu, 8 Aug 2013 14:48:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7A277282E; Thu, 8 Aug 2013 14:48:03 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 55D6EB962; Thu, 8 Aug 2013 10:48:02 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Date: Thu, 8 Aug 2013 10:23:52 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <20130807182858.GA79286@dragon.NUXI.org> <20130807192736.GA7099@troutmask.apl.washington.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201308081023.53040.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 08 Aug 2013 10:48:02 -0400 (EDT) Cc: Arthur Mesh , secteam@freebsd.org, Steve Kargl X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 14:48:03 -0000 On Wednesday, August 07, 2013 4:20:29 pm Peter Wemm wrote: > On Wed, Aug 7, 2013 at 12:27 PM, Steve Kargl > 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