On Sat, 24 Jul 2010, Mario 'BitKoenig' Holbe wrote: > the rng-tools init-script should depend on the start of the sysfsutils > init-script: > Under some circumstances users have to configure which of the available > Hardware RNGs has to be used as "current" RNG for /dev/hwrng before > rngd can start successfully (see below for a full example). This can be > done by setting /sys/devices/virtual/misc/hw_random/rng_current, and > this, in turn, is done by sysfsutils.
No. sysfsutils starts too late for my tastes. The right way to deal with this would actually to hook to udev and select the preferred rng as soon as it becomes available. OTOH, I have nothing against adding support for this feature to rng-tools itself, which looks like a simple way to solve both problems. > Here is the full example if you care :) > I have an IdeaPad S12 VIA Nano where two Hardware RNGs are provided: one > by VIA PadLock through via-rng, and one by the Broadcom Wireless card > through b43. The Broadcom RNG is only delivering data if the wireless > interface is up and otherwise responds ENODEV on read(). This is just a kernel interface shortcoming. We really should have a way for the RNG core to select the highest preference HWRNG (which would be the VIA Padlock one, as it is *FAST*, can generate very high quality random numbers if you configure it appropriately, and has been independently studied and validated in a public place). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
