From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47614) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNKWg-0003sH-4w for qemu-devel@nongnu.org; Thu, 06 Aug 2015 08:44:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZNKWc-0001Nv-K3 for qemu-devel@nongnu.org; Thu, 06 Aug 2015 08:44:01 -0400 Message-ID: <55C35689.2030706@redhat.com> Date: Thu, 06 Aug 2015 14:43:53 +0200 From: Thomas Huth MIME-Version: 1.0 References: <1438849438-18552-1-git-send-email-thuth@redhat.com> <55C34453.3080104@redhat.com> <55C34D79.5010802@redhat.com> <55C35493.2040707@redhat.com> In-Reply-To: <55C35493.2040707@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH] ppc/spapr_hcall: Implement H_RANDOM hypercall List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laurent Vivier , qemu-ppc@nongnu.org, agraf@suse.de, david@gibson.dropbear.id.au Cc: qemu-devel@nongnu.org On 06/08/15 14:35, Laurent Vivier wrote: > > > On 06/08/2015 14:05, Thomas Huth wrote: >> On 06/08/15 13:26, Laurent Vivier wrote: >>> Hi, >>> >>> As "/dev/random" can be blocking perhaps it is possible/better to use >>> the QEMU rng backend instead ? >> >> Actually, I tried to use the rng backends first ... but they turned out >> to be horrible for being used in a synchronous call like I need here: >> You've got to install a callback function which is called at a "random" >> point in time when some data becomes available - and it is even called >> with less bytes than you requested! (i.e. I requested 8 bytes, but the >> callback got only called with 6 bytes). So to use it, I'd have to >> introduce a ring buffer or something similar to query enough random data >> in advance - and when it runs empty, the H_RANDOM hypercall would need >> to block again anyway. >> >> So instead of introducing a hard-to-understand-and-maintain "monster >> wrapper" around the rng backend functions, I think the short and easy >> understandable qemu_random() implementation in this patch here is the >> better choice. >> >> And looking at https://patchwork.ozlabs.org/patch/497062/ I think it >> also should not hurt too much that qemu_random() might be slow here >> since the real hardware number generator is apparently also not very fast. > > It seems a good choice... > > Why do you use buffered file descriptor, fopen/fread/fclose instead of > open/read/close ? You mean to avoid that fread gets some additional bytes in advance? ... that might be a good idea, thanks, I'll change my patch accordingly. Thomas