From: Rusty Russell <rusty@rustcorp.com.au>
To: "lkml" <linux-kernel@vger.kernel.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Subject: [PATCH 01/29] lguest: have --rng read from /dev/urandom not /dev/random.
Date: Fri, 6 Feb 2015 15:51:44 +1030 [thread overview]
Message-ID: <1423200112-5354-2-git-send-email-rusty@rustcorp.com.au> (raw)
In-Reply-To: <1423200112-5354-1-git-send-email-rusty@rustcorp.com.au>
Theoretical debates aside, now it boots.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
tools/lguest/lguest.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/lguest/lguest.c b/tools/lguest/lguest.c
index 32cf2ce15d69..3f7f2326cd9a 100644
--- a/tools/lguest/lguest.c
+++ b/tools/lguest/lguest.c
@@ -1733,9 +1733,9 @@ static void setup_block_file(const char *filename)
}
/*L:211
- * Our random number generator device reads from /dev/random into the Guest's
+ * Our random number generator device reads from /dev/urandom into the Guest's
* input buffers. The usual case is that the Guest doesn't want random numbers
- * and so has no buffers although /dev/random is still readable, whereas
+ * and so has no buffers although /dev/urandom is still readable, whereas
* console is the reverse.
*
* The same logic applies, however.
@@ -1763,7 +1763,7 @@ static void rng_input(struct virtqueue *vq)
while (!iov_empty(iov, in_num)) {
len = readv(rng_info->rfd, iov, in_num);
if (len <= 0)
- err(1, "Read from /dev/random gave %i", len);
+ err(1, "Read from /dev/urandom gave %i", len);
iov_consume(iov, in_num, NULL, len);
totlen += len;
}
@@ -1780,8 +1780,8 @@ static void setup_rng(void)
struct device *dev;
struct rng_info *rng_info = malloc(sizeof(*rng_info));
- /* Our device's privat info simply contains the /dev/random fd. */
- rng_info->rfd = open_or_die("/dev/random", O_RDONLY);
+ /* Our device's private info simply contains the /dev/urandom fd. */
+ rng_info->rfd = open_or_die("/dev/urandom", O_RDONLY);
/* Create the new device. */
dev = new_device("rng", VIRTIO_ID_RNG);
--
2.1.0
next prev parent reply other threads:[~2015-02-06 5:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-06 5:21 [PATCH 00/29] lguest virtio PCI 1.0 adaptation Rusty Russell
2015-02-06 5:21 ` Rusty Russell [this message]
2015-02-06 5:21 ` [PATCH 02/29] lguest: add operations to get/set a register from the Launcher Rusty Russell
2015-02-06 5:21 ` [PATCH 03/29] lguest: write more information to userspace about pending traps Rusty Russell
2015-02-06 5:21 ` [PATCH 04/29] lguest: add infrastructure for userspace to deliver a trap to the guest Rusty Russell
2015-02-06 5:21 ` [PATCH 05/29] lguest: add infrastructure to check mappings Rusty Russell
2015-02-06 5:21 ` [PATCH 06/29] lguest: send trap 13 through to userspace Rusty Russell
2015-02-06 5:21 ` [PATCH 07/29] lguest: suppress PS/2 keyboard polling Rusty Russell
2015-02-06 5:21 ` [PATCH 08/29] lguest: don't disable iospace Rusty Russell
2015-02-06 5:21 ` [PATCH 09/29] lguest: add iomem region, where guest page faults get sent to userspace Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1423200112-5354-2-git-send-email-rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome