From b59aa679226d0775838f87289b60bf9b7c626315 Mon Sep 17 00:00:00 2001
From: cinap_lenrek <cinap_lenrek@felloff.net>
Date: Sat, 27 Aug 2016 21:27:52 +0200
Subject: [PATCH] rand(2), cons(3): clarify /dev/random behaviour

---
 sys/man/2/rand |  4 ----
 sys/man/3/cons | 11 ++++-------
 2 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/sys/man/2/rand b/sys/man/2/rand
index 471c1b607..c091d1521 100644
--- a/sys/man/2/rand
+++ b/sys/man/2/rand
@@ -109,10 +109,6 @@ starting state.
 .I Truerand
 returns a random unsigned long read from
 .BR /dev/random .
-Due to the nature of
-.BR /dev/random ,
-truerand can only return a few hundred bits a
-second.
 .PP
 .I Ntruerand
 returns a uniform random integer
diff --git a/sys/man/3/cons b/sys/man/3/cons
index a12f1cf23..d9f75368a 100644
--- a/sys/man/3/cons
+++ b/sys/man/3/cons
@@ -114,13 +114,10 @@ The hostowner also has group permissions for any local devices.
 .PP
 Reads from
 .B random
-return a stream of random numbers.  The numbers are
-generated by a low priority kernel process that loops
-incrementing a variable.  Each clock tick the variable
-is sampled and, if it has changed sufficiently, the last
-few bits are appended to a buffer.  This process is inefficient
-at best producing at most a few hundred bits a second.
-Therefore,
+return a stream of random bytes produced by the kernels cryptographic
+random number generator. The rate at which data can be read depends on
+the implementation and can vary from hundreds of megabytes to just
+a few hundred bits a second. Therefore,
 .B random
 should be treated as a seed to
 pseudo-random number generators which can produce a faster