Re: random device?

[Rian Hunter]

On Tue, 2004-07-20 at 15:57, Marco Gerards wrote:
> Rian Hunter <hurd@thelaststop.net> writes:
> 
> > On Mon, 2004-07-19 at 11:06, Marco Gerards wrote:
> >> Derek Davies <ddavies@ddavies.net> writes:
> >> 
> >> > Marco Gerards <metgerards@student.han.nl> writes:
> >> >> 
> >> >> It even seems that there is a patch for GNU Mach to add a entropy
> >> >> device...
> >> >
> >> > There's a patch for OSKit/Mach at:
> >> >
> >> >   http://www.ddavies.net/oskit-entropy/index.html
> >> >
> >> > But OSKit/Mach is basically useless unless you're goal is to fix lots
> >> > and lots of bugs.  On and off (mostly off) I work on porting it back
> >> > to GNU/Mach 1.x.  There's nothing hard about this I just find it hard
> >> > to keep focused - someone could pretty easily take the patch above and
> >> > port it.
> >> 
> >> What I meant is that on that site Rian mentioned, in that tarball
> >> there is a patch for GNU Mach 1.x... Or isn't this stuff useful?
> >
> > Just for kicks i tried out the patch at
> > http://ibofobi.dk/stuff/hurd-entropy, but it was made against the 2000
> > gnumach tree, so it doesn't work exactly well. I think the files would
> > have to be manually patched to account for the changes since 2000. So it
> > isn't useful yet, i'll try to get it to work today though because i
> > think a random device is really important. I do think that a user-space
> > entropy daemon is a better way to go though, but since it isn't possible
> > to have a truly competent one under Mach, an in-kernel device is the
> > best way to go for now.
> 
> FYI, this was discussed on the mailinglist.  However, I wonder if they
> are talking about the same thing.
> 
> http://www.mail-archive.com/help-hurd@gnu.org/msg00412.html

moving to: bug-hurd

after reading this it even convinced me more that an entropy gathering
device as a translator in user space is a much better way to go, as it
will be (source) compatible with all Hurds, assuming the interfaces
don't change over time (libtrivfs).

Now either EGD stays it's own project and runs as a regular UNIX daemon,
and the (u)random translators read from that, or

EGD is ported to C (it's written in perl) and made to run as a
translator natively, without the need for a seperate daemon.

pros for first: egd development continues on it's own.
cons: more complication/dependence.

pros for second: random device code is completely isolated into one
binary.
cons: lot's of porting, two "daemons" running (random/urandom),
continued sync up's with main EGD tree, translator will have to be
actively started at boot up.

personally the first solution seems the best, but i'm no hurd veteran so
the second may be more favorable to the design of the Hurd. opinions?
i'll work on this.
-rian