Re: CONFIG_RANDOM option for 1.99.2

Theodore Y. Ts'o (
Tue, 14 May 1996 04:01:48 -0400

From: Paul Gortmaker <>
Date: Tue, 14 May 1996 17:01:44 +1000 (EST)

If we take that approach, then we should remove the CONFIG_PROC_FS
option, as lots of applications require it (ps, w, xload, SNMP-tools,
arp, etc. etc. etc.). Next to go is CONFIG_SYSVIPC, as many things
like tape-buffer programs, the games from ID (doom, abuse) and whatnot
expect that functionality to be present. Also, we might as well remove
both CONFIG_BINFMT_AOUT and CONFIG_BINFMT_ELF, and make both mandatory,
so that commercial vendors can rest assured that one binary will work
on all linux systems.

I'm not being completely sarcastic with the above, as removing these
would have the advantage of removing some of the kernel <--> application
interdependency that exists as in the above examples.

Actually, I think some of these CONFIG options should potentially go
away as well, as they add significant complexity, and confusion on the
part of someone trying to build/configure a linux kernel. Furthermore,
each option exponentially adds more configurations to tests, and for
some of these options, it's not clear when's the last time has tried
compiling with certain features turned off. (For example, it's
currently not possible to use the ext2 filesystem as a module --- but I
bet most poeple never noticed this problem.)

Also, I suspect that where security is involved, people such as the
NetScape crew will be reluctant to use something like /dev/random
over their own internal code, simply because it is code that is not
under their control, and thus represents a substantial risk for them.

Well, the kernel isn't under their control either, and that's a
substantial risk. I've actually been working quite hard to get many
various OS providers (including some major workstations manufacturers)
to include support for /dev/random in their future releases. I am
hoping that one day it will become a standard feature of most Unix OS's.

Also note that the floppy and IDE driver *look like* they use the
add_irq_randomness() because they use a SA_SAMPLE_RANDOM flag with
the call to request_irq(). But they also use SA_INTERRUPT, which means
using do_fast_IRQ() which correctly avoids calling add_irq_randomness(),
as it is only called inside do_IRQ(). In other words, using
SA_INTERRUPT|SA_SAMPLE_RANDOM is functionally equivalent to SA_INTERRUPT.
So to this point in time, it appears that *nobody* has used
add_irq_randomness() yet.

Actually, both of them really shouldn't be using add_irq_randomness
anyway, since they are using add_blkdev_randomness in blk.h. But your
point is well taken that many device drivers haven't yet been modified
to use SA_SAMPLE_RANDOM, and there is the problem of mismatch if the
driver uses "fast" irq service routines.

- Ted