Henrique de Moraes Holschuh writes:
> IMHO, this is mightly annoying to use from inside a rngd-like utility in
> a race-free, safe way. It looks to me that ioctl() would be a much
> better interface for everything but the "enabled" functionality (which
> should be reported to the rngd-like utili
Jason Cooper writes:
> On another thread, regarding the ath9k-rng (actually just the adc
> registers), Henrique asked about per-source knobs. My suggestion
> follows from that.
I'd do that with the source-specific driver instead of attempting to
route controls through hwrng. Anything else seems
Jason Cooper writes:
> Perhaps a /dev/hwrng[0-9] per rng? That would lend itself nicely to a
> sysfs interface for per device quality, rate, and enabled attributes.
> e.g. /sys/class/hw_random/hwrng0/{device/,quality,rate,enabled}
I was interested in the data being provided for /dev/random; tha
Instead of having only one hwrng feeding /dev/random at a time, maintain
a list of devices and cycle between them when filling the entropy pool.
Signed-off-by: Keith Packard
---
drivers/char/hw_random/core.c | 155 +++---
include/linux/hw_random.h | 2
Hardware random number quality is measured from 0 (no entropy) to 1024
(perfect entropy). Allow hardware devices to assert the full range by
truncating the device-provided value at 1024 instead of 1023.
Signed-off-by: Keith Packard
---
drivers/char/hw_random/core.c | 3 ++-
1 file changed, 2
