Date: Tue, 27 Jun 2000 00:46:33 -0600 From: Warner Losh <imp@village.org> To: Mark Murray <mark@grondar.za> Cc: "Jeroen C. van Gelderen" <jeroen@vangelderen.org>, Peter Wemm <peter@netplex.com.au>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/usr.sbin Makefile src/usr.sbin/rndcontrol Makefile random.4 rndcontrol.8 rndcontrol.c Message-ID: <200006270646.AAA32367@harmony.village.org> In-Reply-To: Your message of "Tue, 27 Jun 2000 08:27:42 %2B0200." <200006270627.IAA54693@grimreaper.grondar.za> References: <200006270627.IAA54693@grimreaper.grondar.za> <200006270405.WAA30439@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200006270627.IAA54693@grimreaper.grondar.za> Mark Murray writes: : > Of course you are right. The technique is still a valid one, none the : > less. : : Please have a look at the Yarrow paper at www.counterpane.com. OK. Downloading. : > Now that I think more about this, each device will have its own : > oddball kind of entropy. One idea would be to use an interface : > similar to the shutdown/suspend interface. Tell the nexus about any : > entropy that you've gathered (eg, here, mr nexus, are 12 random bits, : > please add them to the pool). The nexus would walk the tree giving : > all the devices the chance to use those 12 bits. Most devices would : > pass, but the entropy pool pseudo device would consume them. : : I only marginally understand this. Help, please? :-) (I need to : understand what the code to do the nexus attach would look like). The code to attach to nexus looks the same as anything else :-) DRIVER_MODULE(apm, nexus, apm_driver, apm_devclass, 0, 0); s/apm/yarrow/g Probe always returns 1. You'll need an identify routine that adds the device as a child of nexus, if it doesn't already exist (the apm code doesn't check to see if it already exists, which means one cannot unload and reload apm w/o problems). : > If we : > made this device attach to the nexus, or only had the nexus do its : > immediate children, we could optimize this tree walk in the time : > critial section that it would likely be called from (or we may have to : > set a pointer to *THE* entropy pool device and call it directly). : > This would put the onus of the entropy pool gathering in each device : > driver, but that might be OK since we potentially could wrap that in : > some common routines. : : Sounds cool. thanks :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006270646.AAA32367>