Date: Fri, 20 Oct 1995 19:54:50 +0200 From: Mark Murray <mark@grondar.za> To: Bruce Evans <bde@zeta.org.au> Cc: hackers@freebsd.org Subject: Re: Creating a /dev/random Message-ID: <199510201754.TAA02708@grumble.grondar.za>
next in thread | raw e-mail | index | archive | help
> >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510201754.TAA02708>