>>>> There's also an argument that the random number generator causes
>>>> unnecessary overhead for people who never use it, and should therefore
>>>> be made an option. However, I have not yet seen anyone post
>>>> benchmarks or any other form of statistic which might demonstrate that
>>>> such overhead exists.
Someone posted loss of about 5% for read performance.
>>> all right then. I really have no need for /dev/random. Anyone else ?
>>>
>> Personaly I have no need for it too.
>>
> If we go on dropping off useless stuff there are a _lot_ of candidates
> from me...
> - dec alpha stuff
> - mips stuff
> - amiga stuff
> - ide disks
> - all cdroms exept scsi
> - ftape
> I DONT NEED THEM so ergo they are useless. :)
You are right. When you run 'make config', choose 'N' to keep
all that extra code out of your kernel. That's what I do.
Unfortunately, people are stuck with /dev/random because there
is no config option.
/dev/random is less useful than /proc and IPC, both of which are
options. Any argument you can make for requiring /dev/random
applies to IPC and even more so to /proc. What is /dev/random
used for? Why, it is unswappable kernel code that generates
complete garbage at the expense of reduced disk performance...
Next: It might be desirable to collect random events in the kernel.
It is _not_ desirable to store and mix them with a complicated
hash function in the kernel. Put it in a library. If you think
you will need your random data in bursts now and then, have a
daemon collect and serve the random data. The daemon could collect
many megabytes of data on a spare disk. Maybe a daemon that is
suid root (keep /dev/whatever mode 600) which anyone can start when
random data is required. That way the daemon can die after a period
of disuse and be restarted later.
Does anyone else think the kernel has too many checksum/CRC/hash
functions? We need one for Elf, one(?) for networking, and one
for ftape. The decompression code does not need its own CRC.
Neither does the /dev/random.