To: linux-kernel@vger.kernel.org
From: hpa@zytor.com (H. Peter Anvin)
Subject: Re: short read from /dev/urandom
Date: Sat, 15 Jan 2005 02:34:37 +0000 (UTC)
Organization: Mostly alphabetical, except Q, which We do not fancy
Message-ID: <cs9vft$412$1@terminus.zytor.com>
References: <41E7509E.4030802@redhat.com> <20050114191056.GB17481@thunk.org> <41E833F4.8090800@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
NNTP-Posting-Date: Sat, 15 Jan 2005 02:34:37 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1110
Lines: 28

Followup to:  <41E833F4.8090800@redhat.com>
By author:    Ulrich Drepper <drepper@redhat.com>
In newsgroup: linux.dev.kernel
> 
> The code in question comes from a crypto library which is in wide use 
> (http://www.cryptopp.com) and it is using urandom under this assumption. 
>   I fear there is quite a bit more code like this out there.  Changing 
> the ABI after the fact is no good and dangerous in this case.
> 
> I know this is making the device special, but I really think the 
> no-short-reads property should be perserved for urandom.
> 

Does *anything* have it, including files?

I think read() always has the option of returning a short read on
signal delivery.

What urandom has is a no-block guarantee, i.e. the behaviour should be
identical in the presense of the O_NONBLOCK flag, and select/poll
should always indicate that data can be read.

	-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/