Re: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
In article <DHAMpE.34y@sgi.sgi.com>, "Theodore Ts'o" <tytso@MIT.EDU> writes:
Date: Mon, 30 Oct 1995 21:59:14 -0500 From: "Josh M. Osborne" <stripes@va.pubnix.com>
When /dev/random doesn't have "enough" enthropy left does reading from it return an error, or block? I would strongly suggest blocking, as the non-blocking behavur is not really all that useful.
It acts like many character devices and named pipes in that if there is no entropy available at all, it blocks. If there is some entropy available, but not enough, it returns what is available. (A subsequent read will then block, since no entropy will then be available.)
Actually, what's currently in Linux doesn't work precisely like this, but it will soon. After talking a number of people on both sides of the block vs. non-blocking camp, this seemed to be a suitable compromise. At least one Major Workstation Vendor is planning on using this behavior for their /dev/random, to appear in a future OS release. If we all can standardize on this behavior, it'll make application writer's jobs that much easier.
One problem with this scheme is that if multiple processes have /dev/random open you can block unexpectedly. If I try to avoid blocking by first checking if entropy is available there's a race condition if another process reads from the device. Is there another way to avoid blocking? -- Sure we spend a lot of money, but that doesn't mean | Tom Weinstein we *do* anything. -- Washington DC motto | tomw@engr.sgi.com
Tom Weinstein writes:
One problem with this scheme is that if multiple processes have /dev/random open you can block unexpectedly. If I try to avoid blocking by first checking if entropy is available there's a race condition if another process reads from the device. Is there another way to avoid blocking?
Yeah. Use non-blocking I/O. Its in every version of Unix I've touched for over a decade. .pm
Perry E. Metzger wrote:
Tom Weinstein writes:
One problem with this scheme is that if multiple processes have /dev/random open you can block unexpectedly. If I try to avoid blocking by first checking if entropy is available there's a race condition if another process reads from the device. Is there another way to avoid blocking?
Yeah. Use non-blocking I/O. Its in every version of Unix I've touched for over a decade.
I guess I wasn't clear. The message I was replying to defined how the driver decided whether to block. Since I don't have the source code, I was wondering whether non-blocking I/O worked for this driver. -- Sure we spend a lot of money, but that doesn't mean | Tom Weinstein we *do* anything. -- Washington DC motto | tomw@engr.sgi.com
participants (3)
-
Perry E. Metzger -
Tom Weinstein -
tomw＠orac.engr.sgi.com