From owner-freebsd-hackers Fri Oct 20 10:55:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA13066 for hackers-outgoing; Fri, 20 Oct 1995 10:55:18 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA13057 for ; Fri, 20 Oct 1995 10:55:06 -0700 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id TAA29165; Fri, 20 Oct 1995 19:54:51 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id TAA02708; Fri, 20 Oct 1995 19:54:50 +0200 Message-Id: <199510201754.TAA02708@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: Bruce Evans cc: hackers@freebsd.org Subject: Re: Creating a /dev/random Date: Fri, 20 Oct 1995 19:54:50 +0200 From: Mark Murray Sender: owner-hackers@freebsd.org Precedence: bulk > >There is a problem with this. The interrupt handler is called with a unit > >number, which is non-unique. There is no way to get back to the original > >interrupt handler. > > >(you suggested:) > >> I think you will need to hook selected interrupt handlers to get dynamic > >> interrupt information. INTR() is too static. The following would almost > >> work: > >> > >> void init_interrupt_randomness(void) { > >> for (each irq of interest) { > >> prev_intr_handler[irq] = intr_handler[irq]; > >> prev_intr_unit[irq] = intr_unit[irq]; > >> disable_intr(); > >> intr_handler[irq] = add_interrupt_randomness; > >> intr_unit[irq] = irq; > ^^^^^^^^^^^^^^^^^^^^ > This replaces the non-unique unit number by the unique irq number. Sure... > >> enable_intr(); > >> } > >> } > >> > >> void add_interrupt_randomness(int irq) { <-- units, not irq's > units, because the many to one > irq -> unit map has been replaced > by irq -> irq. Yes, but the interrupt routine is _called_ with a non-unique unit. There is no way to get to the original interrupt. > >> (*prev_intr_handler[irq])(prev_intr_unit[irq]); <=== won't work > > as units are mostly > > small numbers > works, because of > the remapping I cant see how. The many -> one is OK, the reverse does not work. > >> >+i386/isa/random.c standard > >> > >> Should be optional. Perhaps `optional random device-driver'. > > >I would rather make it a permanent fixture. When random.c is compiled > >the object file is about 5k, not much for the bloatists to complain > >about ;-). If software developers like Netscrape could count on > >this device being present, then they would use it. If it is optional, > >it may as well be not there. These are Ts'o's sentiments as well. > >Right now there are #ifdef DEVRANDOM constructs around the code, > >which I would like to remove when it is stable. > > I guess the device interface has to be standard and the randomness > calculations, especially the ones that waste time as well as space, > optional. Developers won't like having different interfaces for > Linux, FreeBSD, BSDI, ... Well - this is an attemt to set trends. :-) It is proposed code from the Linux camp - and if it is popular enough, everyone will use it. One way to help this is to make it always present, and then to advertise its presence. BTW - this has an identical user interface to Linux, and is easily transportable to other platforms. I have looked on our Suns at work :-) :-) :-) > >> Does it really have isa dependencies? The other isa includes in machdep.c > >> are bogus too. > > >is this the wrong place to put this header? It is a short file containing > >necessary function prototypes. > > I'm not sure. Does it break on pci systems? If not, then it probably > doesn't belong in /sys/i386/isa. It may even belong in /sys/sys. Don't > worry about this much. The mem driver has many similarly misplaced > things. It's hard to imagine a machine-dependent implementation of > /dev/null, and the implementation of /dev/zero is machine-independent, > and the implementation of /dev/mem is almost machine independent, yet > these devices are mixed with the very machine-dependent /dev/io. I believe it will work on PCI and EISA systems, bit I don't know for sure. I'm mostly easy about wheere this lives. I'm not crazy about sys/sys. There is nothing in ths header that is anyone's business outside the kernel. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key