[EMAIL PROTECTED] said:
> Am I right in thinking that similar code could be used to forward any
> character device?
Yes, but this relies on an existing place to plug in the UML side. So, it
works best when you're implementing some sort of device which has a physical
analog already supported by Li
Excellent, thanks Jeff!
Am I right in thinking that similar code could be used to forward any
character device?
Unrelated question, is skas0 going to work on x86_64 as host or/and as
guest: I mean will I be able to run a x86 kernel on x86_64 with skas? -
there seems to be a few patches that mentio
[EMAIL PROTECTED] said:
> The way it's supposed to be set up is, you install the rng-tools
> package (in SuSE v9.2 distro, or download from http://sourceforge.net/
> projects/gkernel/). rngd periodically reads /dev/hw_random and
> injects the entropy into the /dev/random suite.
In this case,
[EMAIL PROTECTED] said:
> As I understand it, the kernel adds hardware RNG data to the entropy
> pool if the device is available.
Can you give me a pointer to code that does this? I see no hint in random.c
that it takes entropy from the hardware rng.
Jeff
On Thu, 3 Mar 2005, Jeff Dike wrote:
> [EMAIL PROTECTED] said:
> > As I understand it, the kernel adds hardware RNG data to the entropy
> > pool if the device is available.
>
> Can you give me a pointer to code that does this? I see no hint in random.c
> that it takes entropy from the hardware r
On Wed, 2 Mar 2005, Jeff Dike wrote:
> I wrote a little HW random number generator based on hw_random.c. It hooks
> itself up to major 10, minor 183, which seems to be the standard for a
> HW RNG. The standard name for this seems to be /dev/hwrng.
Unfortunately many Intel chipsets lack the har
I wrote a little HW random number generator based on hw_random.c. It hooks
itself up to major 10, minor 183, which seems to be the standard for a
HW RNG. The standard name for this seems to be /dev/hwrng.
I don't know if the ususal random number consumers look for /dev/hwrng before
/dev/random,