From owner-freebsd-arch@FreeBSD.ORG Mon Aug 19 22:01:18 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4D1A0348 for ; Mon, 19 Aug 2013 22:01:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0EB192B9E for ; Mon, 19 Aug 2013 22:01:17 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id uz19so6155616obc.21 for ; Mon, 19 Aug 2013 15:01:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=qwRG+Dpw1Sou4Dc3heoxaX56GgXdPbLuwdzloaqaX7g=; b=cNqg6eaGBEwNOIDSkEbPwGhaKdEkRkL4hWfHA+W3/Bvb3BxXwGq68TMzRdoGGtaoUC RY2cHVIjLdVn19glKTjtRwO03D9oA/vjMVaXMduH4nT5yQrh7+ptlAUM9ir4wHMG1RaT UbwP+3AQsY5lw6uyLcx+NqU9t6/w3p0YyRICxiT/U88tIoROwAvtRPJTGn4WwzrsOA2K e6l+GEEL429RhiccA5stWb4cgtduAaYa5y4SUVnNRW7fUTqnQE5q0S9fySGHza1M9t8C 5t+d4y90v7rJ86KLMp5rHWog7DH8q7nJkyWKCrXdsce9nSAMZX/N9mKdrUfvOJSPyxlL EoDA== X-Gm-Message-State: ALoCoQlLZLD/quaEXcx6oyKcW/7bNtmZpaKoWWpaSx2r1rA/iqPvQPDb2A1lB6MD1QXjCSvDYGHz X-Received: by 10.60.70.134 with SMTP id m6mr15135669oeu.14.1376949671165; Mon, 19 Aug 2013 15:01:11 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id g1sm19684576oeq.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Aug 2013 15:01:10 -0700 (PDT) Sender: Warner Losh Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: Date: Mon, 19 Aug 2013 16:01:07 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <551C488B-D56A-4E9F-8617-17B96D3E7677@bsdimp.com> References: <20130807183112.GA79319@dragon.NUXI.org> <86pptfnu33.fsf@nine.des.no> <20130815231713.GD76666@x96.org> <20130816002625.GE76666@x96.org> <9B274F48-0C88-4117-BEAC-1A555772A3C5@grondar.org> <86a9kf733d.fsf@nine.des.no> <0C97B866-A169-4141-8368-AA7F5B5382F4@grondar.org> <861u5r71zi.fsf@nine.des.no> <892B11BD-396D-4F82-B97C-753F72CA494D@grondar.org> <86r4dr5j3p.fsf@nine.des.no> <4C1BD77C-8C6B-4044-9285-5978A3BC4B70@kientzle.com> <537622E1-F785-4BFA-B829-09DCDB484606@grondar.org> <932AB5CA-778E-438D-8FD3-8C0F29F3D117@kientzle.com> <71A92486-2213-421E-B3D2-E55816C18924@bsdimp.com> To: Mark R V Murray X-Mailer: Apple Mail (2.1085) Cc: Tim Kientzle , =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , secteam@freebsd.org, FreeBSD-arch Arch 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: Mon, 19 Aug 2013 22:01:18 -0000 On Aug 19, 2013, at 1:31 AM, Mark R V Murray wrote: >=20 > On 19 Aug 2013, at 08:18, Warner Losh wrote: >> If we're going to allow passthrough, we should require the kernel = config to explicitly do something to get pass through. >>=20 >> nodevice yarrow >> device random_passthrough >>=20 >> would be my suggestion. >=20 > I don't think it will sell; folks are asking for GENERIC with a = run-time switch to flip between the raw HW generator output and a SW = mixer/conditioner. This is the config for no yarrow and pass through only. If you want = both, you should have both and a sysctl/tunable controlling the = wiring... >> I'd go so far as to say that if you have random in your kernel, then = you need to specify some "filter" or you get a compile-time error. = Specifying yarrow via DEFAULTS or std.foo is fine by me, since both of = those can be overriden fairly easily.... I'd also think we'd want to = FAIL_PANIC or FAIL_BLOCKING, and have that choice hard wired at some = level too, to be explicit about things. But maybe that's gilding things = a bit too much and a tunable would suffice=85 >=20 > Won't sell. Folks are saying they want the choice of the raw output. = In GENERIC. Nothing I've said will preclude it. What's in generic is policy, not = mechanism. > "What Will Sell" may be up for debate and mind-changing; I think that = is the route to explore. Maybe I need to be more articulate, since I'm trying to describe a = mechanism for having one or more filters, but having a compiler error = when there's zero... Warner=