The "yes" utility alrady exists, because it has served a useful purpose,and if someone wants a version that does not append a trailingnewline, I'm sure they can cobble a -n option onto it.

To really emulate this proposed (silly) /dev/repeat, also add a "-" option,which buffers stdin until EOF and the repeats it endlessly. I.e."yes foo" would be equivalent to "echo foo | yes -".

In any case, it can easily and usefully be done in user space.In truth, /dev/null could be, too, but historically it has beenavailable, the kernel implementation is trivial, and it's somewhatmore efficient than a pipe to a data-sink application.

Now, as for /dev/random.../dev/random tries to deliver one-time-pad quality random numbers.These are generated from hardware entropy sources, and are unpredictableto an attacker with infinite computational power. This is extremelydifficult to do from user level, and thus is a valuable service.

/dev/urandom gives numbers that are, in paractice, almost as good.The amount of output /dev/random can generate is limited by thehardware sources. This leads to blocking reads which is, at times,highly inconvenient. The service /dev/urandom provides to userland isthat the numbers are as good as they can be without waiting.

But even though it won't block indefinitely, it's still slow. Fine forgenerating small cryptographic keys directly, but the emphasis is verymuch on security over speed. The intensive speed optimization you seeis all in the interrpt-handler path, where the original entropy isgathered. The code goes to great lengths to avoid delaying that any morethan absolutely necessary. The algorithm trades off time gatheringentropy (into an in-kernel buffer) for time reading the output.

If you want *lots* of random data, that can be done easily in userspace. Choose a cyptographic RNG which suits your speed andsecurity needs, seed it from /dev/urandom, and go to town.

A kernel-level implementation could not possibly be faster that this,and wouldn't offer any security advantages. It's just not necessary.

See my sterilize.c code for an example of how to do it right.(The fallback to /dev/random is because Solaris offers /dev/randombut not /dev/urandom, at least as far as I know.) That code usesa particularly high-speed but somewhat experimental RNG,because it needs megabytes of output. Other applications mightprefer to be a little bit more conservative.

Maybe I should just write up a random-noise-generating utility foruser space?-- -Colin

-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.rutgers.eduPlease read the FAQ at http://www.tux.org/lkml/