lkml.org 
[lkml]   [1996]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: CONFIG_RANDOM (compromise?)
Date
> From: Lauri Tischler <ltischler@fipower.fi>

>>>> 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.



\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.055 / U:1.716 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site