From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51033) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNHBP-0002IN-Pc for qemu-devel@nongnu.org; Wed, 03 Apr 2013 02:28:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UNHBM-0006MD-5Q for qemu-devel@nongnu.org; Wed, 03 Apr 2013 02:28:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:11683) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNHBL-0006Ln-U8 for qemu-devel@nongnu.org; Wed, 03 Apr 2013 02:28:28 -0400 Date: Wed, 3 Apr 2013 11:58:23 +0530 From: Amit Shah Message-ID: <20130403062823.GA8995@amit.redhat.com> References: <74d06e1f94cc2337aa1bb6784a7ad2210ec55364.1364808312.git.amit.shah@redhat.com> <87eheus60p.fsf@codemonkey.ws> <20130402103549.GC15084@amit.redhat.com> <874nfpf62k.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <874nfpf62k.fsf@codemonkey.ws> Subject: Re: [Qemu-devel] [PATCH 1/1] rng backend: open backend in blocking mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu list On (Tue) 02 Apr 2013 [07:52:19], Anthony Liguori wrote: > Amit Shah writes: > > > On (Mon) 01 Apr 2013 [09:02:46], Anthony Liguori wrote: > >> Amit Shah writes: > >> > >> > Opening backends in non-blocking mode isn't necessary, we don't do > >> > anything while waiting for data. > >> > > >> > This also excuses us from checking for EAGAIN, which for the default > >> > random backend, is a very common return error type. > >> > >> It's not common... It really shouldn't happen however. > > > > EAGAIN is common when a file is opened in non-blocking mode. Needs to > > be made verbose? > > EAGAIN doesn't just happen randomly. It only happens when you read from > an fd when no data is present. Normally, that is something that is > predictable. When we open /dev/random as the default backend, we should expect more EAGAINs than data :-) i.e. /dev/random blocks, we know it. > >> > backends/rng-random.c:44:entropy_available: assertion failed: (len != -1) > >> > > >> > without this fix. > >> > >> This fix would cause QEMU to block indefinitely which I don't think is > >> very good behavior. I think a better solution would be: How about relegating it to glib functions, and hooking it up so that /dev/random is polled for data, and this function gets called when /dev/random has data to give out? Sure, when a read is attempted, there might be no data available again, but we could then go back to polling. Amit