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 ? Laurent
