Date: Thu, 24 Aug 2000 01:48:32 -0400 (EDT) From: Louis Gerbarg <gerbal@rpi.edu> To: freebsd-hackers@FreeBSD.ORG Subject: A few device questions Message-ID: <Pine.A41.3.96.1000824011035.91774B-100000@vcmr-19.rcs.rpi.edu>
next in thread | raw e-mail | index | archive | help
I have been working with the OpenBSD /dev/random driver, and have ported it to Darwin. While I was at I wanted to also port it to FreeBSD, because it is more functional then current one, but I have a few questions: In OpenBSD random has its own major, whereas in FreeBSD it is part of the mem major. I assume that it should be kept part o the mem major? Assuming I do that I basicly was going to make the memdriver calls check for the random minors, and if it was one call the appropriate call from the OpenBSD random driver. The mem driver does not seem to have an attach call. To hack around that on darwin I used a static variable initialized to 0, and then put a test for it in the open call. If it is zero it runs my attach routine and sets the variable to 1. Is there a better way to do this in the FreeBSD mem driver? The OpenBSD driver does not support the poll call, but one of the FreeBSD one does. I prefer the OpenBSD semantics, but is there a reason why poll is available for one of the random devices? I also patched the libkern random routine, so that it calls the same backend as /dev/urandom. This is equivalent to /dev/srandom until it runs out of entropy, then degenerates to /dev/prandom, which is basicly equivalent to the current algorithm. This allows all of the kernel random routines to get better quality random. Do other people think this is a good idea? I also modified theier random driver to use sha1 instead of md5, because it was simpler for a number of reasons. In OpenBSD that is in /usr/src/sys/crypto/, where would it go in FreeBSD? Also there seems to be a vestigial version of seperate random driver kern/kern_random.c (Attic). Is there any reason why the code was moved directly into the architexture specific mem.c. It seems to me that the random code should be platform neutral, and that placing it in the mem driver causes a significant increase in complexity in certain cases. Thanks for your time, it may be that I am just entirely off base, but I think that improved random code could be pretty useful. Louis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.A41.3.96.1000824011035.91774B-100000>