Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH] ppc/spapr_hcall: Implement H_RANDOM hypercall

[Thomas Huth <thuth@redhat.com>]

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