From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53148) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UP5GQ-0004Nm-Fw for qemu-devel@nongnu.org; Mon, 08 Apr 2013 02:09:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UP5GK-0005yd-Oj for qemu-devel@nongnu.org; Mon, 08 Apr 2013 02:09:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:65407) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UP5GK-0005yR-HL for qemu-devel@nongnu.org; Mon, 08 Apr 2013 02:09:04 -0400 Date: Mon, 8 Apr 2013 11:39:00 +0530 From: Amit Shah Message-ID: <20130408060900.GH16207@amit.redhat.com> References: <74d06e1f94cc2337aa1bb6784a7ad2210ec55364.1364808312.git.amit.shah@redhat.com> <87eheus60p.fsf@codemonkey.ws> <20130402103549.GC15084@amit.redhat.com> <874nfpf62k.fsf@codemonkey.ws> <20130403062823.GA8995@amit.redhat.com> <87ehercr7b.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ehercr7b.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 (Wed) 03 Apr 2013 [15:08:40], Anthony Liguori wrote: > Amit Shah writes: > > > On (Tue) 02 Apr 2013 [07:52:19], Anthony Liguori wrote: > >> Amit Shah writes: > >> > >> >> > 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. > > The fix I posted minus the needed s/EINTR/EAGAIN/g is pretty straight > forward and IMHO the proper way to handle this. > > Is there something you think is broken with it? I guess I should turn > it into a real patch but I was hoping you would so I didn't have to > recreate the original problem :-) Oh yes, I'll do that and test, and will submit a patch. My concern is just that we'll forget checking for EINTR and fall into these traps with open-coded read() calls instead of using wrappers. Amit