From owner-freebsd-hackers Wed Aug 23 22:48:12 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 5715E37B424 for ; Wed, 23 Aug 2000 22:48:10 -0700 (PDT) Received: from vcmr-19.rcs.rpi.edu (vcmr-19.rcs.rpi.edu [128.113.113.12]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id BAA557476 for ; Thu, 24 Aug 2000 01:48:09 -0400 Received: from localhost (gerbal@localhost) by vcmr-19.rcs.rpi.edu (8.8.5/8.8.6) with SMTP id BAA137388 for ; Thu, 24 Aug 2000 01:48:32 -0400 X-Authentication-Warning: vcmr-19.rcs.rpi.edu: gerbal owned process doing -bs Date: Thu, 24 Aug 2000 01:48:32 -0400 (EDT) From: Louis Gerbarg X-Sender: gerbal@vcmr-19.rcs.rpi.edu To: freebsd-hackers@FreeBSD.ORG Subject: A few device questions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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