Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 2 Dec 2000 13:35:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 2 Dec 2000 13:35:09 -0500 Received: from mandrakesoft.mandrakesoft.com ([216.71.84.35]:29469 "EHLO mandrakesoft.mandrakesoft.com") by vger.kernel.org with ESMTP id ; Sat, 2 Dec 2000 13:34:56 -0500 Date: Sat, 2 Dec 2000 12:03:56 -0600 (CST) From: Jeff Garzik To: Igmar Palsenberg cc: Matthew Kirkwood , folkert@vanheusden.com, "Theodore Y Ts'o" , Kernel devel list , vpnd@sunsite.auc.dk Subject: Re: /dev/random probs in 2.4test(12-pre3) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 2 Dec 2000, Igmar Palsenberg wrote: > > Indeed, you are correct. Is vpnd broken then, for assuming > > that it can gather the required randomness in one read? > > Yep. It assumes that if the required randommness numbers aren't met a read > to /dev/random will block. > > And it's not the only program that assumes this : I also did. > > /dev/random is called a blocking random device, which more or less implies > that it will totally block. I suggest we put this somewhere in the kernel > docs, since lots of people out there assume that it totally blocks. "totally block"? For a blocking fd, read(2) has always blocked until some data is available. There has never been a guarantee, for any driver, that a read(2) will return the full amount of bytes requested. There is no need to document this... man read(2) ;-) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/